A brief (hah) historical note :-) ...

>AFAIK, the device-driver hook existed to support a Gross Hack 
>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.

Although the br and cvec description is correct (specifically, they
were r11 and r10 respectively), this was only for Unibus drivers,
and the register save-mask update was done inside the Unibus code
itself, during autoconfiguration itself.

The original device-driver flag caused the original config to run
`c2 -i'; the -i flag mainly told c2 not to change the size of any
memory reference.  (For instance, `branch on bit set' does a byte
reference, while `branch on low bit set' does a longword reference.
The c2 optimizer normally considered them equivalent and would
translate a `jbs $0,(r7),Lfoo' to `jlbs (r7),Lfoo'.  If r7 pointed
to a device register, this could wreak havoc.)

(I once asked Robert Elz why br and cvec were not simply global
variables.  It turns out that he and someone at Berkeley, most
likely Bill Joy -- although several people were involved in all
this and there is an interesting background story about Eunice and
Dave Kashtan here -- were busily adding hack after hack to make
the new code better/faster/stronger, and one of those hacks was
replacing the original br&cvec globals with the save-mask trick.
Another was that fancy sed script that inlined the calls to spl[0-7],
mfpr/mtpr, etc.)

Clearly, this is all pretty irrelevant to modern compiler technology,
although flagging device drivers as `device-driver' is not a big deal
either way.

Also:

>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. 

Old config did *not* support that with the `cpu' keyword; in fact,
the old cpu keyword was exactly the same as `options', except that
(a) it did not allow a value (you could not say `cpu "VAX780"=13')
and (b) the old config refused to continue if the machine-description
file did not have at least one `cpu' keyword.

(Indeed, you could say:

	ident	"VAX780"
	cpu	"VAX750"
	options	"VAX730"

and get the same effect as the obvious three `cpu's.  I removed
`ident' and `cpu' precisely because of their redundancy.  [Well,
ident also had a limited sort of `include' facility, but the new
config had a less-limited one.])

>... cpu support doesn't seem quite like other config
>options, IMHO: it should be more like a device or a pseudo-device.

On those machines on which a cpu is like a device or pseudo-device,
just declare it as one.

Chris