[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Question to throw at you guys

From: olafBuddenhagen
Subject: Re: A Question to throw at you guys
Date: Tue, 14 Nov 2006 05:42:19 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

This didn't seem to have got through, resending...


On Sun, Nov 12, 2006 at 10:57:32PM +0000, Justin Emmanuel wrote:

> I would also like to know your comments criticisms on the concept of
> what I like to call a Driver Description Language.

First of all, it's not possible to write really safe drivers (at least
for PC-style hardware), no matter what language you use, because many
hardware is able to do dangerous things like DMA, and there is no
uniform interface to access such dangerous features. To prevent
destructive hardware access, you have to know the specific hardware in
question -- which is in fact precisely the job of the driver. In short:
You can't protect hardware from it's driver.

The best you can do for safer drivers, is to create minimal trusted
drivers for accessing the actual dangerous hardware functionality, and
then let all the higher-level driver functionality (abstraction) run in
a different, untrusted process -- either a dedicated server, or maybe
even a library linked to the actual applications. That is the approach
used by GGI/KGI for graphics hardware drivers, and it's similar to the
general exokernel approach.

All the safeguards that *can* be implemented to make drivers less
dangerous, like limiting their access to system resources and hardware
registers to those they might actually need for their operation, can be
implemented perfectly well when running drivers as distinct user space
processes -- completely independent of the language they are written in.

With a user space driver framework, you can easily write each driver in
a different language, so every programmer is free to choose the language
that makes it easiest for him to write drivers in. Having a special
language for driver development would only limit possibilities and make
development harder, not easier. In fact, with user space drivers, it's
even possible to write drivers like ordinary application software, using
the normal C library etc. -- a while back I've written a proposal for
such a framework for the original Hurd/L4, still available at
http://belug.de/~antrik/posix_drivers.txt .

As for portability, this is also pretty much orthogonal from the
programming language. You can perfectly well create driver portability
frameworks for traditional languages like C. Guess what? It already has
been done: See UDI ( http://www.project-udi.org/ )

This approach however doesn't work out in practice, because people
interested in drivers for a popular system will just write drivers for
this system's native driver framework, not caring about portability to
other systems; and for less popular systems, hardly anybody will write
drivers at all, no matter whether there is a portability framework or

In fact, it is pretty reasonable to write drivers directly for the most
popular system's framework, and let other systems emulate this framework
(like gnumach does with the Linux driver glue code) -- effectively
treating it as a portability layer. Sure, emulating such a specific
framework on other systems is quite hairy; but in practice, it's often
more efficient than programming everything against a framework that
tries to abstract for all kinds of very different systems in advance.

The drivers running in such an emulation framework of course won't be
optimally using the specific system's abilities, but so won't drivers
written for some portability framework in the first place.

The only problem we are facing here is that the most popular free
kernel, and thus the most interesting source to borrow drivers from, is
Linux; but this one changes it's internal interfaces pretty often,
making it relatively hard to keep up with glue code. :-(


reply via email to

[Prev in Thread] Current Thread [Next in Thread]