Re: APIs and compatibility

[Neal H. Walfield]

At Mon, 01 Sep 2008 13:57:50 -0400,
Jonathan S. Shapiro wrote:
> 
> On Sun, 2008-08-31 at 11:55 +0200, Neal H. Walfield wrote:
> > At Sat, 30 Aug 2008 14:02:40 -0400,
> > Jonathan S. Shapiro wrote:
> > > It strikes me that rebuilding a very large number of drivers as a
> > > precondition to success is probably not a good recipe.
> > > 
> > > Is there any reason why the linux driver framework cannot be adopted
> > > directly by l4-ng?  I do understand that user-supplied drivers are
> > > desirable, and I think that remains possible in all of the practical
> > > use-cases that have come up here.
> > 
> > Although custom drivers offer the best potenial quality, writing new
> > drivers for all hardware is impractical.  So there must be some reuse.
> > However, some reuse does not imply that all drivers must be reused.
> > That is, very common hardware or essential hardware can be provided by
> > native drivers and the rest by way of reuse.
> 
> I agree with all of these points. But this does imply that certain
> *interfaces* from Linux become mandatory: those that in SVR4 would have
> been called the "Driver Kernel Interface". This is ad hoc in Linux, but
> it exists.

I don't see why you think this.

Assuming that the OS has its own interface for accessing devices,
reusing Linux device drivers does not mean that this interface must be
abandoned or that the Linux interface must be exposed to applications.
A server that implements the normal interface can be used to translate
from one to the other.

The limitation is that the OS interface cannot be easily implemented
in terms of the Linux interface.  For instance, there may be issues
with proper accounting of resources.  I address this below.

> > This hair can be avoided by reusing Linux in its entirety.  In this
> > case, Linux is run on a VMM and the new operating system makes calls
> > to the Linux driver instance.  Two examples of this are Afterburner or
> > Xen.  Both use a paravirtualized Linux instance.
> 
> But if this is done, what is the advantage of having a microkernel at
> all?

There are two arguments:

First, I am trying to develop a way to first of all safely empower
applications.  From a pure research perspective, I am not interested
in creating a product but verifying my ideas.

But, let's say some community picks up my ideas (or even my code
base).  It is true that the advantages will be reduced.  However, if
the new OS proves successful, custom, more appropriate, drivers will
be written.

Second, even in the cases that they are no custom drivers,
applications are still significantly more controlled.  I think that
this is the major source of problems.  From a security perspective, I
want to, e.g., control the plug-ins my browser uses.  From a
performance perspective, I want to enable applications to make better
uses of resources.  These are both largely accomplished without custom
drivers.

Neal