Re: Deva interface

[Neal H. Walfield]

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

The client must always wait.  If the client requires an asynchronous
reply (for some reason), then its only choice is to spawn a thread
which waits for the reply on its behalf.  So, you have the right idea.

> *I tried to design some interfaces for deva.
> 
> deva should respond to at least these RPCs:
> 
> -enumerate
> -open
> -close
> -read
> -write
> -map

This is a good start.  We will also need a way to get some properties
of devices such as the preferred block size, the size of the device
(in the case of block devices) etc.  The list can always be extended
later depending on the actual needs (instead of perceived needs) of
the device drivers and the users.

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

I am not sure I follow.  deva provides an interface to devices.  How
this gets translated to fabrica is an implementation detail.  Why not
have a capability per-device open?  Basically, have deva provide a
normal filesystem which can be mounted.  It would be similar to "/dev"
but only contain the real and not logical (i.e. virtual) devices.

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

If deva is a filesystem then the root directory would be fabricated by
deva as a function of the 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.

Maybe.  The plug-in manager definitely knows what is loaded, however,
deva needn't maintain a list in that case: it can just query the
plug-in manager.

>   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 think there will be multiple plug-in managers.  My reading of
the current specification is that each bus reports to the same central
plug-in manager.  Either way, enumeration is not the fast path and
that is a minor detail at this stage.

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

The plug-in manager should receive all unplug events: it needs to
notify users.

> *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.

Why?  Do you really thing device names will be longer than 63 (the
number of message resiters not including MR0) * (sizeof l4_word_t)
characters?

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

Maybe.  Names are nicer but we can see what is more convenient later.

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

I see no reason not to support some subset of hurd/fs.defs and
hurd/io.defs (however, they will look on the Hurd/L4 port) in this
way, deva can be a proper Hurdish filesystem translator.

Thanks,
Neal