Hi Linus,
The implementation of bcopy() in lib/string.c (and some other places such as
the XFS header files) is incorrect as it implements bcopy as memcpy. This is
wrong: bcopy should be the equivalent of memmove (which handles overlapping
areas correctly).
I've dicussed it with a number of people, and the general consensus seems to
be that it should be nuked entirely? Do you agree?
David
On Mon, Oct 07, 2002 at 02:57:12PM +0100, David Howells wrote:
>
> Hi Linus,
>
> The implementation of bcopy() in lib/string.c (and some other places such as
> the XFS header files) is incorrect as it implements bcopy as memcpy. This is
> wrong: bcopy should be the equivalent of memmove (which handles overlapping
> areas correctly).
Kernel bcopy in traditional unix versions never supported overlapping.
That's what ovbcopy() is/was for.
On Mon, 7 Oct 2002, David Howells wrote:
>
> I've dicussed it with a number of people, and the general consensus seems to
> be that it should be nuked entirely? Do you agree?
I agree. bcopy should just DIE. Some architectures may have historical
trouble with gcc emitting bcopy for structure assignments (and that's
definitely a memcpy with no overlap), but I think that's long gone (I know
gcc on alpha used to do this several years ago).
XFS seems to be a big user of bcopy, though..
Linus
On Mon, 7 Oct 2002, Mike Galbraith wrote:
> >
> >XFS seems to be a big user of bcopy, though..
>
> Does it matter from the cleanliness side? (1->N users)
It does.
I will not apply a patch that removes bcopy() in the name of
"cleanliness", if it then results in a number of modules just adding their
own
#define bcopy(a,b,c) memcpy(b,a,c)
because then the whole cleanup would be pointless - it would just make
some modules even uglier than they were before.
So I'd much rather see the XFS etc code moved away from bcopy() first,
because that's the _real_ cleanup. The library code isn't all that ugly in
comparison.
Linus
On Mon, Oct 07, 2002 at 11:08:19AM -0700, Linus Torvalds wrote:
> So I'd much rather see the XFS etc code moved away from bcopy() first,
> because that's the _real_ cleanup. The library code isn't all that ugly in
> comparison.
The lowlevel XFS code tries to stay in sync as much as possible with
the IRIX codebase to make maintaince easier (we're a very small team..).
It could be removed, but I don't think it would help..
On Mon, 7 Oct 2002, Matthew Wilcox wrote:
>
> The only user of bcopy() in the entire kernel which wasn't _already_
> using a #define was in arch/ia64/sn/io/module.c, and i fixed that as
> part of the patch.
The thing is, if the choice is between a #define and a bcopy() function,
I'd rather take the function and get rid of the #define instead.
Are there any XFS people that can be shamed into doing a
search-and-replace and do this right?
Linus
On Mon, Oct 07, 2002 at 11:08:19AM -0700, Linus Torvalds wrote:
> So I'd much rather see the XFS etc code moved away from bcopy() first,
> because that's the _real_ cleanup. The library code isn't all that ugly in
> comparison.
The only user of bcopy() in the entire kernel which wasn't _already_
using a #define was in arch/ia64/sn/io/module.c, and i fixed that as
part of the patch.
--
Revolutions do not require corporate support.
On Mon, 7 Oct 2002, Christoph Hellwig wrote:
>
> The lowlevel XFS code tries to stay in sync as much as possible with
> the IRIX codebase to make maintaince easier (we're a very small team..).
Could somebody drag the Irix team kicking and screaming into the 1980's,
please?
I realize it might be quite painful for them, but maybe you could buy them
a disco tape, so they'd feel a little bit more at home.
Linus "Stayin' alive, stayin' alive" Torvalds
Linus Torvalds wrote:
> On Mon, 7 Oct 2002, Christoph Hellwig wrote:
>
>>The lowlevel XFS code tries to stay in sync as much as possible with
>>the IRIX codebase to make maintaince easier (we're a very small team..).
>
>
> Could somebody drag the Irix team kicking and screaming into the 1980's,
> please?
>
If it were that simple I'm sure it would have been done long
ago, no?
> I realize it might be quite painful for them, but maybe you could buy them
> a disco tape, so they'd feel a little bit more at home.
>
The Bee-gees are annoying, they'll do fine.
> Linus "Stayin' alive, stayin' alive" Torvalds
>
No comment ;-)
-Stan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
[email protected] (Stan Bubrouski) wrote on 07.10.02 in <[email protected]>:
> Linus Torvalds wrote:
> > On Mon, 7 Oct 2002, Christoph Hellwig wrote:
> >
> >>The lowlevel XFS code tries to stay in sync as much as possible with
> >>the IRIX codebase to make maintaince easier (we're a very small team..).
> >
> >
> > Could somebody drag the Irix team kicking and screaming into the 1980's,
> > please?
> >
>
> If it were that simple I'm sure it would have been done long
> ago, no?
How can it *not* be that simple?
No matter if you think bcopy should work for overlapping memory or not,
there is a replacement standard function (by the 1989 ANSI C standard, so
maybe the 1980's are not quite modern enough) that does exactly that, with
nothing but rearranged parameters.
That's a purely mechanical change, on the same level as the kernel janitor
stuff - hell, easier than the kernel janitor stuff.
I expect the reason it hasn't been done in Irix kernel code is simly that
there was no real need to do it. I certainly do not imagine there's
anything *hard* about it.
Hell, you could just use the #define method to map an XFS memcpy (or
memmove) onto the Irix kernel library bcopy!
No, this is politics, not technical. (On both sides, of course.)
MfG Kai