Subject: Re: "esp" driver reorg proposal
To: None <firstname.lastname@example.org>
From: Gordon W. Ross <email@example.com>
Date: 01/28/1997 16:12:40
> From: firstname.lastname@example.org (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...