Re: Deva interface

[markus kaarn]

Marcus Brinkmann wrote:

> 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.
>  
What do you mean here by "shring memory for I/O"?

In abstract, if user wants driver to transmit/receive data from device 
for it,
user must provide buffer for the operation, if needed.
If that is the case, then driver must acknowledge that memory is valid
by requesting some info from physmem. Or memory must be somehow acknowledged
before refering to device-driver.

Or maybe the driver itself should provide buffer, where user can 
read/write if needed,
(assuming that driver always knows the cost of operation requested by user).
i.e. if one needs to read 512Kb(one sector) from Hdd.  User passes that 
to driver
by showing, that he needs these 512Kb, and waits for driver to return 
with pointer
to memory containing data he needs. Of course, you say - who releases 
memory after
user read it - but mechanisms can be worked out.

This is abstract, so don't take this werry critical plz. 8)

> 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?).
>  
Yep, got a point here.
Write drivers for devices used now-days, and firstly, devices
we use.

p.s. I don't know much on capabilities right now. But i'm on my way. ;')

Thanks,
Markus