On Tue, Nov 06, 2007 at 08:42:48AM +0100, Franck Bui-Huu wrote:
> > Older gcc used to generate significantly worse code for inline functions
> > than for macros so Linux became a fairly excessive user of macros. This
> > has very much improved since, so these days inlines are prefered over
> > macros where possible.
> Yes but ISTR that gcc generates some calls to memset and since
> builtin functions are disabled the final link failed if memset
> is inlined. I'll try to reproduce...
So both belt and suspenders then that is an inline/macro plus an outline
> >> Yes I noticed this. Actually I'm wondering if we couldn't add a new
> >> function, fill_user() like the following:
> >> extern size_t fill_user(void __user *to, int c, size_t len);
> > That's much better function name than the old __bzero - except that
> Actually I named it '__fill_user', since it doesn't call access_ok().
> > __bzero effectivly took a long argument for the 2nd argument so 32-bit
> > on 32-bit kernels and 64-bit on 64-bit kernels.
> Isn't size_t meaning ?
> Perhaps in this case __kernel_size_t is better...
I wrote about the existing __bzero which takes the size_t length as third
argument and a long sized fill pattern as the second.
> Yes I have a patchset which clean up a bit uaccess.h and does this but
> it's under construction. It actually tries to convert all macros into
> inlines and the file is much more readable and as a bonus side we could
> easily add __must_check annotations which are currently missing.
> I'll try to finish it this week but in the meantime can we just kill
> __bzero or do you want me to include it in the future patchset ?
There is enough time until 2.6.25 to complete your cleanups; no more
cleanups for 2.6.24.