> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol
> Cc: cgd@cs.cmu.edu, tech-kern@netbsd.org
> Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Mon, 27 Jan 1997 17:41:01 -0800
> Sender: thorpej@nas.nasa.gov
> 
> 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 :-)

I was hoping to see an argument in support of the binary interface
way that was supported with something more tangible than the purely
asthetic issue of "consistency" and "enforced abstraction."  This is
not just personal definsiveness - I'd really like to question what
appears to be existing practice and see it objectively defended.

[ Using "N copies" of a <machine/xxxvar.h> file is... ]
>  > 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

I'm not concerned about the autoconfig code.  I wouldn't want to
bother trying to share that.  The duplicated code I was referring to
is the actual functions that the function pointers reference, and
the section of code in the attach function that initializes all the
function pointers.  That comes out to something larger than what it
takes to accomplish the same thing using a <machine/xxxvar.h> file.

So, using function pointers has an advantage of "purist" isolation,
but it DOES have a practical cost, and I'm hoping to hear some sort
of practical (not asthetic) justification of that cost.

As a practical matter, the method I proposed does not require any
coding at all; it simply moves some stuff around.  If that is not
acceptable (which clearly appears to be the case) then someone will
have to write a bunch of glue code before we can have a shared
ncr53c90 driver.  I've got too much else to do already, so I'm
not going to volunteer to do it right now.

So, perhaps a better question is, "would we rather have a less
beautiful shared ncr53c90 driver using <machine/xxxvar.h>, or
would we rather continue using separate copies until someone
finds time to write binary glue?"  Probably the latter. :-/

Gordon