Subject: Re: "esp" driver reorg proposal
To: Gordon W. Ross <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 01/26/1997 00:36:35
> > > The functionality that is provided by the current macros in the header
> > > files could be provided by function pointers.
> > "yes."
> 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.
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.
(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.
Why export the headers to user-land if they have no meaning in
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.
(It's worth noting, for those of you out there watching, I do
intend <machine/bus.h> to be used by user-land programs
(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-).