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 version? > >> 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. Ralf
