> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Sat, 25 Jan 1997 14:26:52 -0800

[ names... ]

> Ok... since it's going to live in sys/dev/ic... :-)
> 
> 	sys/dev/ic/ncr53c9x.c		(note, lack of "esp" and "asc" :-)
> 	sys/dev/ic/ncr53c9xreg.h
> 	sys/dev/ic/ncr53c9xvar.h

I sort of prefer the _older_ name, i.e. dev/ic/emulex100.c
but I don't care too much about names.

> 	sys/arch/alpha/tc/esp.c		(not on tc; really on tcds)
> 	sys/arch/sparc/dev/esp.c	(multiple attachments in one file)
> 	sys/arch/sun3x/dev/esp.c
> 
> I do _not_ like the notion of <machine/espvar.h>, or whatever.  That
> doesn't scale; perhaps you have some weird machine that has a 53c9x
> on two very different busses... "oops!"

Actually, it scales just fine (I did think about that issue).
It gives much more flexibility to the port using the driver if
we leave the choice of dispatch mechanism up to the MD code.
If the port needs to support the driver on two different busses,
then it's <machine/espvar.h> would simply define the appropriate
macros to expand to the "dispatch on bus type" functions; and if
it does not need that, it is not forced to "pay" for it.

After all, letting MI code pull in MD headers is pretty much the
fundamental software architecture used in our kernel -- and for
good reason: it works well.

Gordon