Charles Hannum <mycroft@mit.edu> writes:

>Simon Burge <simonb@telstra.com.au> writes:
>> While talking about config(8), is it worth thinking about keeping
>> config(8) in /usr/src/sys somewhere?
 

>Really, the preferred solution here is to just avoid needing to change
>config(8) often.  It's true that the switch to config.new(8), and then
>the cf_attach changes, caused incompatibilities.  However, all of the
>changes I've proposed are backward compatible (or at least *can* be,
>if we leave default `S?=' lines in the Makefiles) with 1.2.

I agree with Charles.

AFAIK, the device-driver hook existed to support a Gross Hack when
compiling Vax device drivers.  registers.  The "br" and "cvec" local
register variables in a device probe function, apparently normal C
locals, then become pass-by-value/restore arguments.

A script edited the assembler output of pcc to change the vax
entry-point masks for registers 9 and 10 (or 10 and 11?), where it
was known the compiler  would put  "br" and "cvec".   The locore code
then used those registers, after the probe function returned
successfully, to set up Vax hardware interrupt vectors.
Maybe device-driver also had special semantics for memory access:
this all predated the "volatile" keyword.

There really is no reason to support this, and it should die.



While changes for config are up for grabs, can we add a section
to support configuring for different levels, or models, of a target
platform?  Old config used to support this with the "cpu" keyword.
Most ports are now supporting this with ad-hoc options. 

I think that configuring for a particular member of a CPU family can
and should be supported directly, in some way more like the old-config
"cpu" keyword.  cpu support doesn't seem quite like other config
options, IMHO: it dbe shoul more like a device or a pseudo-device.
Maybe putting them into a 'config-dependent' section or adding a new
section would work?