Re: APIs and compatibility

[Neal H. Walfield]

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.


Regard reuse, I am aware of 2 main approaches to getting drivers that
don't involve writing new drivers: port the drivers or port linux.


Porting drivers has been done over and over again.  The major problem
that has been encountered over and over again is that it is difficult
to describe the Linux API.  For instance, some functions depend on how
the CPU scheduler works.  This is further complicated by the fact that
the Linux driver API is not stable and evolves with each new release.

To simplify driver reuse, OSKit provided a general framework for
driver reuse.  The idea was to require that the underlying OS
implement a well-defined API and handle Linux API quirks in the OSKit.

OKUJI Yoshinori ported the Linux 2.0 drivers to GNU Mach in 1998.
This worked fairly well, however, has provden fragile and difficult to
maintain.

Over the past decade, TU Dresden has maintained the DDE Kit.  As I
understand it, this is essentially OSKit specialized for L4.  Talking
to those who have worked on this, they also confirm that support the
API subtilties is a pain.


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.


Assuming that the system is so far that the limiting factor is
drivers, I think the best approach is to reuse Linux as a whole:
porting drivers is just too hairy.  Between the afterburner approach
and the Xen approach, I would go with the latter.  From a practical
perspective, Xen has the major advantage that it is commercially
maintained and provides a relatively stable API.


Neal