Re: Deva interface

[Marcus Brinkmann]

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.

But at the driver level, it is just some wired memory area, mapped
into the drivers address space, with a known physical memory address
(so that you can do DMA with it).  All the details how to share memory
with untrusted users are taken care of by deva.

Certainly, due to the nature of the Hurd system, there will be some
Hurd policy that influences heavily the driver framework, but we
thought that the whole capability system etc should not be imposed.

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?).

Thanks,
Marcus