[Top][All Lists]

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

Re: Deva interface

From: R. Koot
Subject: Re: Deva interface
Date: Tue, 18 Jan 2005 02:45:50 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Marcus Brinkmann wrote:
At Mon, 17 Jan 2005 19:03:22 +0100,
"R. Koot" <address@hidden> wrote:

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.

The reason we don't want it that way is that we don't want to impose
Hurd mechanisms on the device driver framework.  Consider a
complicated case like sharing memory for I/O.  This is a complex
operation, which will include some concepts like "trusted buffer
objects", or "containers" in our vocabulary.  And those are
represented in the Hurd by capabilities to the physmem server, and
there is a lot of policy involved.

Hmmm, I problably should have explained why I drew the driver in a double box in my very nice picture.

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

It is a a wrapper layer (which would be rather thin on the HURD, a little bit thicker if you wanted to use the same driver on Linux). I don't think a driver should use anything HURD specific or even know Deva exists.

To wait for an interrupt the driver would make a very generic interrupt_wait( interrupt_t ) call. This unction would be provided by the wrapper. On the HURD this would probably calls Deva (which passes some capabilities around, communicates with wortel and L4...). On Linux the wrapper would aquire spinlocks, hack some structures, create bottomhalves, feed tux, something with tophalves, ...

As long as you use enough abstract types, generic calls and don't try to create an ABI, portable drive should be possible. Even memory mappings don't require anything HURD specific. Since each call would pass through the wrapper it could figure out (,aybe with the help of Deva) is it a authorized mapping and then handle capabilities and containers before the real driver gets called. Interface design would help also be only allowing upward mappings (form the application to the driver) and have the wrapper make a check that it wasn't unmapped when a call is made that uses the shared memory.

I enjoyed reading your explanation of the ISA bus.  One thing that may
make things simpler for us though is that we decided to not focus on
support for legacy hardware, but go for the modern stuff first.  So
ISA support is optional IMO (does anybody disagree?).

Unfortunatly until nobdy uses his/her floppy drive anymore, you will need support for ISA DMA. Support for ISA soesn't require any hacks or 'dirty' interfaces. It just requires to make the interfaces a little bit more flexible. Instead of phys_alloc( size ) you would uses a phys_alloc( size, maxaddress, alignment ). You will need this call anyway, becuse when you run the HURD on EMT64 (but not AMD64 due to an IO-MMU I believe) with PCI cards that only support 32-bit memory access you will run into the same problem. Will you require people to throw away their old hardware, because the HURD was 'designed to run on modern hardware'?


reply via email to

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