Subject: Re: "esp" driver reorg proposal
To: Gordon W. Ross <gwr@mc.com>
From: Charles M. Hannum <mycroft@gnu.ai.mit.edu>
List: tech-kern
Date: 01/28/1997 15:39:54
"Gordon W. Ross" <gwr@mc.com> writes:
>
> /*
> * This file should exist as <arch/sparc/include/espvar.h>
> * so <dev/ic/esp.c> can include it as <machine/espvar.h>
> */
>
> #include <machine/autoconf.h>
> #include <sparc/dev/sbusvar.h>
> #include <sparc/dev/dmareg.h>
> #include <sparc/dev/dmavar.h>
>
> #define ESP_DEBUG 0
>
> /*
> * Machine-dependent things in esp_softc
> */
> typedef u_char esp_reg_t;
> typedef struct dma_softc esp_dma_t;
> struct esp_sc_md {
> struct sbusdev scmd_sd; /* sbus device */
> struct intrhand scmd_ih; /* intr handler */
> int scmd_pri; /* SBUS priority */
> };
> #define sc_sd sc_md.scmd_sd
> #define sc_ih sc_md.scmd_ih
> #define sc_pri sc_md.scmd_pri
>
> /*
> * Macros to read and write the chip's registers.
> */
>
> #define ESP_READ_REG(sc, reg) \
> ((sc)->sc_reg[(reg) * 4])
>
> [...]
This is *exactly* the sort of thing we're trying to get away from!
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?
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.