Date: Sat, 07 Dec 1996 13:30:59 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: dyson@freebsd.org, bde@zeta.org.au, cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/include endian.h Message-ID: <199612070531.NAA27469@spinner.DIALix.COM> In-Reply-To: Your message of "Sat, 07 Dec 1996 00:21:08 EST." <199612070521.AAA00201@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"John S. Dyson" wrote:
> >
> > "John S. Dyson" wrote:
> > > >
> > > > Most of the kernel doesn't pick up the CPU options.
> > > >
> > > Why not? That seems to be unwise, shouldn't anything with any
> > > 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.
> > >
> > > John
> >
> > Perhaps we should seriously consider using 'cc -include opt_global.h' and
> > moving things like Ix86_CPU etc into there? It has the benefits of having
> > every file know about the settings, but without having to modify every file
.
> >
> Other flags that might eventually be used would be the SMP ones? Imagine
> the #ifdefs (or macros that are conditional on #ifdefs) that there
> will eventually be when/if we do fine grained locking...
Funny you should mention the smp case, I very nearly mentioned it.. It's
a prime example of where we're facing adding opt_smp.h to a very large number
of files.
I would also like to see all "unrecognised" options go into opt_global.h
as well, that will finish the 'make depend' fixes... ie: make depend
will be 100% safe, but unrecognised option changes will imply a complete
recompile... but that's better than requireing a complete recompile always
as it currently stands.
> John
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612070531.NAA27469>