Re: Deva interface

[Neal H. Walfield]

> I agree with you on that as well.  What this is about is to make it so 
> easy to write a driver for our framework, that our framework will be 
> ported to other systems.  Then people will like to write such 
> "platform-independant" (no doubt excluding Windows) drivers, because 
> they can be used by everyone without change.

I am sorry to say that I think this is a Utopian vision.

> Interfaces may be 
> large, drivers don't need to implement it all.

Interfaces should be minimal.  A good interface provides precisely
what is required and not more.  Everything should exist for a reason.

> > But the killer argument is that all this work is mostly useless if we
> > are the only ones doing and using it, because then almost nobody wins
> > anything: We still have to modify all the software out there, and all
> > the software still needs to have the small drivers for all the other
> > systems.
> 
> At the moment, a separate driver is needed for every system.  As far as 
> I understood it, the reason of making the ddf not use any hurd-specific 
> features was to make it portable.  I like that idea very much.  It would 
> make it possible to write a single driver for several systems.  We will 
> have to see if that is what happens, but at least it's good that it's 
> possible. :-)

The ddf is built around L4.  It is not supposed to be a universal
driver framework.  The problem with aiming for ultimate generality is
that too much abstraction translates to lower perform because there
will always be assumptions which do not fit the underlying system's
and that there is a lot of extra hair trying to meld interfaces (in
this case the ddf and the rest of the OS).

Will there be assumptions about our architecture in the ddf?  You bet.
Especially if they translate to large performance increases.  The
reason that we are not just using the Linux kernel drivers and writing
glue code is that they don't fit the assumptions of our system, for
instance, the way memory is handled.  Will our drivers fit the
assumptions of the Linux kernel?  Maybe.  But certainly not 100%.  I
agree that we should aim for reusable code but I don't think we should
place independence from the rest of the operating system as the prime
mover.

> Since there is no such system available at this moment, we cannot simply 
> use it (otherwise we should, IMO).  So we should start it ourselves, and 
> hope others will use ours.

Consider OSKit [1] and UDI [2].


[1] http://www.cs.utah.edu/flux/oskit/
[2] http://uw714doc.sco.com/en/UDI_config/CONTENTS.html