From owner-cvs-sys  Fri Dec  6 21:32:04 1996
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA05967
          for cvs-sys-outgoing; Fri, 6 Dec 1996 21:32:04 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA05919;
          Fri, 6 Dec 1996 21:31:55 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id NAA27469;
          Sat, 7 Dec 1996 13:31:00 +0800 (WST)
Message-Id: <199612070531.NAA27469@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 
In-reply-to: Your message of "Sat, 07 Dec 1996 00:21:08 EST."
             <199612070521.AAA00201@dyson.iquest.net> 
Date: Sat, 07 Dec 1996 13:30:59 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-sys@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

"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