Subject: Re: "esp" driver reorg proposal
To: None <firstname.lastname@example.org>
From: Gordon W. Ross <email@example.com>
Date: 01/26/1997 00:54:08
> From: "Chris G. Demetriou" <firstname.lastname@example.org>
> Date: Sun, 26 Jan 1997 00:36:35 -0500
> > > > The functionality that is provided by the current macros in the header
> > > > files could be provided by function pointers.
> > They could, yes, but that is not the ONLY way, and I've yet to see
> > any explanation as to why it SHOULD be the only way permitted.
> None of these nail the coffin shut, but:
> (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?
> Given that the point of making a driver machine-independent
> is to seperate the 'stuff that the device needs' from the
> 'stuff that the machine/bus/whatever' needs, there should be
> no _need_ to allow direct manipulation of the MI driver
> by the MD code.
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.
> (2) avoids proliferation of <machine/xxx.h> files.
> In my opinion, the things in <machine/*> should have _some_
> bearing on user software, i.e. included by headers included
> from user-land or directly from user-land programs. Obviously
> that is not true for all headers, but it is true for most of them.
This is a whole different issue. There are many header files in
arch/*/include that should not be exported to user-land, but that
problem exists only because we do not (yet?) have any separate
place for the kernel-only headers.
> Saying that each and every MI driver is going to do this
> (which is what you should do, if you start making this a trend)
> means that there would be N (where N is potentially the number of
> MI drivers) extraneous headers in /usr/include/machine. That
> seems wasteful and unnecessary to me.
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.
> (3) several other MI drivers do it this way (rather than the way you
> propose), and it's the 'preferred' method (as described by people
> in 'core' who care, and me 8-).
Existing practice is not always the best practice.