Date: Fri, 04 Apr 2003 23:03:56 +0200 From: des@ofug.org (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) To: Kris Kennaway <kris@obsecurity.org> Cc: cvs-all@FreeBSD.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 src/sys/sparc64/sparc64 support.S ... Message-ID: <xzppto2c6v7.fsf@flood.ping.uio.no> In-Reply-To: <20030404173635.GA22147@rot13.obsecurity.org> (Kris Kennaway's message of "Fri, 4 Apr 2003 09:36:36 -0800") References: <200304041729.h34HTtVb027430@repoman.freebsd.org> <20030404173635.GA22147@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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() c= all, > > to take care of the KAME IPv6 code which needs ovbcopy() because NetB= SD's > > bcopy() doesn't handle overlap like ours. > Was this for optimization reasons, hysterical raisins, or some other reas= on? 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 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 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. 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. DES --=20 Dag-Erling Sm=F8rgrav - des@ofug.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzppto2c6v7.fsf>