Hi, 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 not. 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. :-( -antrik- _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
