> > > 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
    that context?

    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
    eventually...  8-)

(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-).




cgd