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.