Re: Deva interface

[Vittore Scolari]

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.
>
>
> Ruud

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.

comments?

Vittore