Re: Deva interface

[R. Koot]

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'?



Ruud