cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 identcpu.c support.s src/sys/i386/include md_var.h src/sys/i386/isa npx.c src/sys/ia64/ia64 support.s src/sys/powerpc/powerpc bcopy.c sr

[Bruce Evans]

On Fri, 4 Apr 2003, Dag-Erling [iso-8859-1] Smørgrav wrote:

> Kris Kennaway <kris at obsecurity.org> writes:
> > On Fri, Apr 04, 2003 at 09:29:55AM -0800, Dag-Erling Smorgrav wrote:
> > >   Define ovbcopy() as a macro which expands to the equivalent bcopy() call,
> > >   to take care of the KAME IPv6 code which needs ovbcopy() because NetBSD's
> > >   bcopy() doesn't handle overlap like ours.
> > Was this for optimization reasons, hysterical raisins, or some other reason?
>
> The existence of ovbcopy()?  I imagine it was just an API issue,
> someone didn't feel comfortable assuming that the kernel bcopy()
> handles overlap when the userland version doesn't.  In FreeBSD

I think the problem is more the reverse.  The userland bcopy() has handled
overlap (and has been documented to do so) since at least FreeBSD-1.1.
It's hard to see how the BSD bcopy() family could work if bcopy() didn't
handle overlap, since this family has no other member corresponding to
Standard C's memmove().

> however, ovbcopy() has always (for appropriate values of "always")
> been an alias for or duplicate of bcopy().  On i386, ovbcopy() was an
> alternate name for bcopy from its inception in revision 1.1 of
> locore.s (originally from 386BSD) until revision 1.40 (late 1996) when
> Bruce made it a trampoline (and bcopy() a function pointer) to allow
> for multiple processor-specific versions.  On powerpc, it was a

I only made bzero a function pointer.  bcopy() and ovbcopy() are still
functions.  They just use a trampoline internally.

> separate function but an exact duplicate of bcopy() (which itself is a
> wrapper for memcpy()).  On all other platforms, it was an alternate
> name for bcopy().
>
> In NetBSD, the situation is a little confused, because most platforms
> use a generic C implementation of bcopy() (in libkern) which handles
> overlap, but some use optimized assembler versions which don't, and
> these platforms have ovbcopy() - but the only part of the tree which
> actually uses ovbcopy() is the IPv6 stack (KAME), and it has its own
> version (a macro wrapper for memmove()) so in effect the real
> ovbcopy() is never used.

Urgh.  This is a good example of the morass you can get into with
micro-optimizations, especally when everyone/everyarch doesn't know
about and/or want all of their details.  And this is without even
the complications for memcpy vs bcopy, compiler builtins for memcpy
and C inlines for memcpy.

> The current situation in FreeBSD (after my commits) is much like that
> in NetBSD, except we have no real ovbcopy() at all, just a macro in
> <sys/systm.h> for KAME's benefit.

The main problem with the commit is not mentioned in its log message:
changing bzero from a function pointer back to a function breaks
binary compatibility of many modules.  In defence of this, 5.0 breaks
binary compatibility of most modules for other reasons.

Bruce