> From: mycroft@gnu.ai.mit.edu (Charles M. Hannum)
> Date: 28 Jan 1997 15:39:54 -0500

[ sample sparc/include/espvar.h removed for brevity ]

> What happens when some smartass builds a Sbus<->ISA adapter?  Are you
> going to change all the `shared' device drivers to support it?  Are
> you just not going to bother?

If the port wants to support the driver on multiple bus types, then it
would needs to define things like ESP_READ_REG() as:

#define ESP_READ_REG(sc, reg) \
	BUS_READ_8((sc)->sc_reg[(reg) * 4])

and I don't see how that removes any possibility of supporting
multiple busses.  This basically puts on level of name redirection
under control of MD code, so the MD code can either short-circuit
the bus* stuff or define the access macros in terms of bus* macros.

> The point of /dev/ic, and of the bus.h abstraction, is to separate the
> code into modular chunks (chip driver, chip<->bus (board) interface,
> bus<->cpu interface).  In your proposed model, you've combined the
> chip<->bus and bus<->cpu interfaces, requiring me to modify every
> single machine/xxxvar.h in order to support a new bus.

They are only combined in the sample I provided because the sparc
has no need for indirection.  I don't see a technical problem with
letting the MD code decide whether to access registers directly or
use bus_space_read_1() and such.  You may find it "ugly," but I
don't consider that a "technical" problem.

So, I'm still waiting for an explanation of the tangible benefit
of forcing all ports using the driver to call a function on each
access to a device register...

Gordon