From owner-cvs-all Mon Sep 25 15:15: 3 2000 Delivered-To: cvs-all@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id CD53637B43E for ; Mon, 25 Sep 2000 15:14:51 -0700 (PDT) Received: (qmail 31330 invoked from network); 25 Sep 2000 22:14:46 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 25 Sep 2000 22:14:46 -0000 Date: Tue, 26 Sep 2000 09:14:40 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys libkern.h In-Reply-To: <200009252111.PAA56527@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 25 Sep 2000, Justin T. Gibbs wrote: > >You mean memcmp and memset (memcpy was already a (non-inline) function). > >This mistake in -current shouldn't have been propagated. > > The mem\* routines are part of the C standard and should be available > from within the kernel. This doesn't follow. Only the freestanding implementation part of the C standard is generally available in the kernel. > I don't think that a piece of code that runs > on multiple platforms should have to role their own mem\* routines. Code that supports lots of platforms will probably need to do this anyway. E.g., the isp driver #defines MEMCPY and MEMZERO. This takes a whole 0.5% of isp_freebsd.h. > If you don't like what Poul-Henning did, then implement something better, I complained to him privately about implementation bugs in the libkern changes, but he didn't reply. They were in the wrong file to begin with. They should have been in systm.h where the prototypes are. After a quick'n'wrong fix for this, we now have libkern.h and systm.h including each other (not recursively, due to the idempotency ifdefs, just ugly). His previous change in rev.1.78 of param.h, to generate an error if memcpy (sic) or memset is used in the kernel, would have been almost correct if it hadn't been completely broken by confusing memcmp with memcpy. After doing never merging the libkern breakage and fixing subsequent collateral breakage in randomdev, I get only the following errors for building LINT: aml_name.o: In function `aml_local_stack_create': aml_name.o(.text+0x611): undefined reference to `memset' awi.o: In function `awi_ioctl': awi.o(.text+0x3a8): undefined reference to `memcmp' awi.o(.text+0x3c3): undefined reference to `memset' awi.o: In function `awi_init': awi.o(.text+0x6e4): undefined reference to `memset' awi.o: In function `awi_input': awi.o(.text+0x153c): undefined reference to `memcmp' awi.o: In function `awi_init_hw': awi.o(.text+0x1dd1): undefined reference to `memcmp' awi.o: In function `awi_init_mibs': awi.o(.text+0x2012): undefined reference to `memset' awi.o: In function `awi_start_scan': awi.o(.text+0x251e): undefined reference to `memset' awi.o: In function `awi_stop_scan': awi.o(.text+0x27cc): undefined reference to `memcmp' awi.o: In function `awi_recv_beacon': awi.o(.text+0x2a43): undefined reference to `memcmp' awi.o(.text+0x2a59): undefined reference to `memcmp' awi.o(.text+0x2ad0): undefined reference to `memset' awi.o: In function `awi_recv_auth': awi.o(.text+0x335c): undefined reference to `memcmp' awi.o: In function `awi_recv_asresp': awi.o(.text+0x36f4): undefined reference to `memcmp' awi_wicfg.o: In function `awi_cfgget': awi_wicfg.o(.text+0x394): undefined reference to `memset' awi_wicfg.o(.text+0x5e9): undefined reference to `memset' awi_wicfg.o: In function `awi_cfgset': awi_wicfg.o(.text+0x8e6): undefined reference to `memset' awi_wicfg.o(.text+0x97e): undefined reference to `memset' if_awi_pccard.o: In function `awi_pccard_probe': if_awi_pccard.o(.text+0xc9): undefined reference to `memcmp' At least awi used to have a home made memcmp and memset to work around this error. The broken memcmp in libkern was copied from there. > but the old situation where modules would compile with some compiler > options and not others is not acceptable. Anything that is checked by putting it in NOTES and building LINT won't be broken by -fno-builtin, but controlling the builtins by replacing them by inline functions would be better. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message