Date: Sat, 5 Apr 2003 16:22:23 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@ofug.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: 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 Message-ID: <20030405160449.L37042@gamplex.bde.org> In-Reply-To: <xzppto2c6v7.fsf@flood.ping.uio.no> References: <200304041729.h34HTtVb027430@repoman.freebsd.org> <xzppto2c6v7.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Apr 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Kris Kennaway <kris@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 Ne= tBSD's > > > bcopy() doesn't handle overlap like ours. > > Was this for optimization reasons, hysterical raisins, or some other re= ason? > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030405160449.L37042>