> From: "Chris G. Demetriou" <cgd@cs.cmu.edu>
> 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.

Gordon