Deva interface

[Matthieu Lemerre]

Hi,

This time I tried to address some more specific issues about deva
interfaces with client apps.

*One on my first concerns was about asynchronous calls that Mach
 provided. They are used in some places in the Hurd on Mach.

 On L4, the client cannot do such an asynchronous call because deva
 must not block on the client, even for a small time (quoting Marcus:
 Servers must never block on sending messages to clients.  Even a small
 timeout can be used for DoS-attacks.)

 But I think that it would be possible to emulate this behaviour if the
 client spawns a new thread which does the synchronous call, and just
 wait for it when it need to be sure that the operation on the device
 is completed.

 Is there a problem with this scheme that I did not see?

*I tried to design some interfaces for deva.

deva should respond to at least these RPCs:

-enumerate
-open
-close
-read
-write
-map

I think that one coherent way to do this would be the following:

-deva serves "ddf thread access capability", that is a capability to
 access a thread running inside the ddf. As these threads only trust
 themselves and deva, this ensure that we have to use deva as a proxy
 to contact them. On deva's side, the capability object would contain
 the thread id.

-For instance, deva may serve a "ddf device driver thread access
 capability", and it would be on these capabilities that the client
 would call the methods "close, read, write, map". Deva would then
 make a call to the device driver, transmitting the given parameters
 (maybe checking them before).

-Deva could also serve a "default plugin manager thread access
 capability", and on this capability we would call the methods
 enumerate and open. Then deva would contact the plugin manager to get
 the list of available devices.

This assume that the plugin manager has the list of all loaded
device drivers, which may not be the case:

  Loading drivers is handled by the plugin manager, which asks deva for
  the binary, so both know what device drivers are currently loaded.

  However there is a problem if there is several plugin manager, and the
  device driver list is stored in several parts in each: we have to
  contact them all for each open/enumerate. I don't know if it is an
  expensive operation.

  I don't know neither if deva is notified on an unplug event from a bus
  driver, so deva could not be aware of which drivers are no more
  present (eventually we could add this notification to deva).

  So, I don't know if it is better if this driver list is stored in
  deva or in the (default?) plugin manager. However, it doesn't change
  many things for the interface.

*Another problem I encountered was that on "naming device drivers":
 what should the result of an enumerate be?

 Mach used strings to name the devices, but I think this would be
 difficult to do if we don't support string items.

 So a collection of numbers (like the major and minor on UNIX, except
 that we can use words to store these number and thus not fearing not
 to have enough numbers) could be a good idea to identify a device.


I hope that these interfaces match what you've been thinking of.


Thanks,
Matthieu