linux-mips
[Top] [All Lists]

Re: [PATCH] Kill __bzero()

To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: [PATCH] Kill __bzero()
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 6 Nov 2007 10:36:03 +0000
Cc: linux-mips <linux-mips@linux-mips.org>
In-reply-to: <47301AF8.2000700@gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> <472F906F.7080205@gmail.com> <20071105231818.GA18820@linux-mips.org> <47301AF8.2000700@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.14 (2007-02-12)
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

<Prev in Thread] Current Thread [Next in Thread>