On Sun, 26 Jan 97 00:54:08 EST 
 "Gordon W. Ross" <gwr@mc.com> wrote:

 > > (1) enforcement of modularity.  If drivers can't muck with the MI
 > >     driver's internals, they won't be tempted to.
 > 
 > Bondage and dicipline, eh?

...not really.  More like consistency and enforced abstraction :-)

 > To me, "the point" (purpose) of the proposed reorganization is to
 > allow the bulk of the driver source code to be shared.  I am too
 > practical to demand that it ALL be shared, and I am not interested
 > in "bondage and dicipline" approaches to software engineering.
 > I want software that makes it convenient to get the job done.

...That's the purpose of _all_ machine-independent drivers.  The
"bondage and discipline" approach seems to have worked very well
in the case of the LANCE and 5380 drivers.

The needless duplication of code you refer to, I think, is mostly
because the SPARC and Sun 3 ports are (gratuitously?) different in
how they handle DVMA.  Eventually, I'd like those differences to
be hidden by bus.h, and have the Sun DVMA handling goop used by the
5380 driver moved into sys/dev/sun :-)  (Autoconfiguration will
probably always be slightly different on these systems, and forcing
them to be the same is probably a little overzealous.)

 > No more wasteful than the N copies of machine-dependent "glue" code
 > that is necessary with a strictly "binary interface" (no provision
 > for an MD header to affect the MI code).  In fact, I'll claim that
 > the amount of replicated code is smaller using the MD header.

Erm, well...

I'm not so sure... In the case of e.g. the LANCE or 5380 drivers,
the "glue" code is mostly autoconfiguration, anyhow, which is
something that can't really be hidden inside macros (this is especially
true in the LANCE driver).  In the 5380 driver, there are some places
where there's duplicated code, esp. in the case of the VME attachments
on the Sun 3 and SPARC ports... however, the OBIO attachments of these
are different because of hardware, and autoconfiguration is different
because those ports have different needs in that area...

The mac68k and pc532, which both use PDMA, implement it differently
because of different hardware restrictions... there's not a lot of
duplicated code there, either...

Now, if we think about the case where you have a FooBar ZapStation,
which comes in the Whuzzle and Zoobie models, each of which have
an NCR53c94 on very different busses, you'd have to do dispatching
for each macro call.  I.e., take the case of ESP_READ_REG():

static __inline u_char ESP_READ_REG __P((struct esp_softc *, int));
static __inline u_char
ESP_READ_REG(sc, reg)
	struct esp_softc *sc;
	int reg;
{
	u_char v;

	if (sc->sc_bustype == WHUZZLE) {
		/* do Whuzzle stuff */
	} else {
		/* so Zoobie stuff */
	}

	return (v);
}

That has the possiblity of unnecessarily increasing code size, and
paying the cost of extra comparisons, as more ZapStation models
are introduced.  Also, it may be necessary to call bus-specific
functions inside of this macro or inline, which inappropriately
exposes that bus to the outside world.

This just makes me feel better about setting up a set of function
pointers once at attach time.

So, realistically, I think the amount of actual "duplicated" code
is quite small, and an acceptable trade-off to the (IMO) increased
flexibility and modularity of the resulting code.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939