Christoph Hellwig wrote:
On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote:
On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote:
xfs_macros.c is a mess. If you want to do a service to everyone
kill it and the surrounding machinery and just leave the macros,
without the out of line instances.
I don't like xfs_macros.c either, but my understanding
was that it still needs to be around, so as not to diverge
from the Irix code. At least that is my understanding
based on reading this thread:
That was about changing them to functions, which is a) an intrusive
change and b) very debatable. Just leave the macros and remove the
whole expand the macros to out of line functions alternatively logic.
If one of them is to big we can change it to a function call later
more easily after this initial change.
I can give you some history on this if it helps
There were a couple of reasons for the functions vs macros thing (it
predates me too, so don't blame me for the code ;-).
1. Being able to compile as functions meant breakpoints could be
used in the code. I do not remember the last time that happened.
2. There were some Irix platforms with more limited kernel address
spaces, for these, a tradeoff was made between speed (inline code
via a macro), and the space it used. Apart from embedded systems
which might want to use XFS for some reason, I suspect this is no
longer an issue, I do not have a good feel for what the smallest
XFS code size vs the biggest might be.
If someone converts all the code to plain macros, I suggest you look
carefully at the ones which default to being functions, these are
probably the main culprits when it comes to code bloat. With today's
fast cpus, keeping them as functions might still be worth while
from a code size point of view.