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>
index | next in thread | previous in thread | raw e-mail
On Fri, 4 Apr 2003, Dag-Erling [iso-8859-1] Smørgrav 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 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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030405160449.L37042>