From owner-cvs-sys Fri Dec 6 21:32:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA05971 for cvs-sys-outgoing; Fri, 6 Dec 1996 21:32:05 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA05864; Fri, 6 Dec 1996 21:31:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA16289; Sat, 7 Dec 1996 16:29:42 +1100 Date: Sat, 7 Dec 1996 16:29:42 +1100 From: Bruce Evans Message-Id: <199612070529.QAA16289@godzilla.zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Subject: Re: cvs commit: src/sys/i386/include endian.h Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, dyson@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Most of the kernel doesn't pick up the CPU options. >> >Why not? That seems to be unwise, shouldn't anything with any Because opt_cpu.h is only included in the few places where it is needed, just like other options files, so that everything doesn't depend on it. This can't be fixed by including opt_cpu.h in endian.h, since apart from defeating the dependency optimization, opt_cpu.h doesn't exist when endian.h is included by applications. Some applications define KERNEL so KERNEL can't be used to control the inclusion. A new postive logic, option would work right. It can be kept out of opt_cpu.h. >cpu specific inlines also pick-up the CPU options? Anything >that uses endian.h (or cpufunc.h) are perfect examples of where >there might be some value in that. Not now. None did. The inlines and macros can be treated as a library and cpu-dependent ones can be chosen in the places that use them. This is unwieldy for the ntoh* functions since they are used a lot. Bswap is the only generally useful instruction in ix86's that isn't always available, so there are unlikely to be more cases like this for ix86's. Bruce