From owner-cvs-src@FreeBSD.ORG Fri Apr 4 22:22:43 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D6337B401; Fri, 4 Apr 2003 22:22:43 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57E1143F85; Fri, 4 Apr 2003 22:22:41 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA25634; Sat, 5 Apr 2003 16:22:24 +1000 Date: Sat, 5 Apr 2003 16:22:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20030405160449.L37042@gamplex.bde.org> References: <200304041729.h34HTtVb027430@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Kris Kennaway 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 06:22:43 -0000 On Fri, 4 Apr 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Kris Kennaway 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 > 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