Re: XFS_WANT_FUNCS

[Steve Lord <lord@xxxxxxx>]

Andi Kleen wrote:

> On Sun, Jan 11, 2004 at 10:21:43AM -0600, Glen Overby wrote:
>  
>
> > When we build XFS kernels with the DEBUG define set, it turns those
> > macros into C functions (see xfs_macros.c).  This is so stack traces
> > will show what macro a problem occurs inside of, and so breakpoints
> > can be set inside of macros.
> >    
>
> It sounds like inline functions would serve your goal better. When
> you have a kernel with debug information you can see exactly
> the line the fault occurs in then. You could even define the "inline" away
> to them them into normal static functions, although that would probably
> not be too useful (except maybe for KDB). They would also be a lot more
> type safe.  You can also still set breakpoints in the, although only
> per file, not global.
>
> I can do a patch to convert them to inlines if there are chances that
> it will get merged.
>
> -Andi
>
>  

The other thing these macros let you do is switch between inline code 
and out of
line code based on how big you want xfs to be in code size. Some of the 
macros
expand to a lot of code and are actually always compiled as functions to 
avoid
too much code bloat.  Probably a one off decision on inline code vs function
calls should be good enough for modern machines, that mechanism was more
concerned with making xfs run on 32M memory Irix boxes. All the definitions
in xfs_macros.h control this.

But yes it is a pain to read through them - and you should try writing 
new ones ;-)
The scary part about moving things to inlines would be xfs's tendency to 
push
gcc to its limits on ia32. This type of thing is what has caused broken code
generation in the past.

Steve