Date: Sat, 7 Dec 1996 16:29:42 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, dyson@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/include endian.h Message-ID: <199612070529.QAA16289@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>> 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. Brucehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612070529.QAA16289>