[Top][All Lists]

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

Re: Deva interface

From: Vittore Scolari
Subject: Re: Deva interface
Date: Tue, 18 Jan 2005 15:51:39 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804

R. Koot wrote:

+--------+     +--------+     +--------+     +--------+
|        |     |        | --> |  Deva  | <-> |+------+|
|  The   | --> | Direct |     +--------+     ||Driver||
|  Game  |     |  Axe   |                    ||      ||
|        |     |        | -----------------> |+------+|
+--------+     +--------+                    +--------+

In a multi-server OS applications/services can and should talk directly with the drivers. This means deva doesn't have to specifiy/provide the interfaces to them. Deva should just manage drivers (load/unload/power-mangement) and provide an interface to let applications find devices.

I think it would be best if each driver prvides several separate interfaces. One general interface that communicates with Deva and a few that communicate with services (which abstract the device further to a 'POSIX device' for example). A video driver would contain a basic video interface that does mode-setting and framebuffer-mapping, but could also contain an interface for 2D acceleration and one or more interfaces for 3D acceleration (OpenGL, 3Dfx, DirectX-ish,...). The closer it gets to how the real hardware does it the better the performance. These kind of thing would just be very hard to doe with read/write/ioctl.


Flexibility is all that a device driver system need so

I think ideally it would be:
The Driver (ddf), a l4 server providing only a simple layer over the hardware, whith non standard interface. it should own capabilities to make some system calls.

Deva-driver: a library or service which connect deva to the ddf driver giving deva (or the driver) a common read/write/ioctl/map unix interface(that's the real posix driver). It should be easy to write this Deva-driver, or no one would write drivers for the hurd. So there must be some sort of common libraries for various device-classes.

Deva: a server that menages drivers and bus-drivers, receives plug unplug etc events, and talk to the plug-in manager for taking actions. It would also serve a /dev like file-system and interact whith glibc giving a posix emulation layer to the user. It would also implement basic services to the ddf(or better, to the Deva-driver).

HID and the console: services that mix-audio, switch-consoles, controls the mouse etc...

The next needn't to be implemented in the kernel
[X, Open-gl, Direct-x, open-as, video4linux...]-driver: libraries which connect [X, Open-gl, Direct-x, ...] (one library for each [X, Open-gl, Direct-x, ...]) to the ddf driver and the console giving the ddf driver a common interface for all devices appartaining to a class (like the deva-driver, but this time linked to the library). (That's the way modular X.org works) [X, Open-gl, Direct-x, open-as, video4linux...]: libraries and services that the user use to have full featured performances

With this configuration for example if texas-instruments wanted to make a spectrometer GPL driver they can use the Deva-driver for spectrometers, implement a ddf server that can do much more and implement an user space libraryforspectometer-driver that use those extensions. If the situation for spectometer sucks like now and there is not a libraryforspectometer, they can always sell their program with an integrated closed library that connect to the GPL ddf server. The point is that physicians have the GPL ddf driver open, have acces to the more simple functions of the spectometer through deva, and so can write their GNU fortran 77 programs :) that use the device. they are also encouraged to write an open-source libraryforspectometer.

The only problem remains security. I am not much concerned with this since i am not a computer science student or professor (i can (and i hope to) help only for quite high level stuffs). but i suspect that leaving access of ddf servers interfaces to any user library without some sort of ACL (or hurd capability-like system) is dangerous.

Also it look like ddf can and should became a little hurd in the hurd, much complicated, whith many levels of abstraction, with many libraries, with containers, capabilities and such.



reply via email to

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