Re: Questions about the device driver framework

[Marcus Brinkmann]

At Fri, 14 Jan 2005 03:40:44 +0100,
Matthieu Lemerre <address@hidden> wrote:
> * I don't see well how the ddf will communicate with outside-ddf
>   applications, for instance user applications. I was first thinking
>   that deva would act as a proxy between the two, but in fact I
>   recently understood that deva was just a server "or a library?"
>   providing access for the ddf to some ressources managed by the OS
>   personality.

Does it matter if deva is a library, a server, or fabrica a library
used by deva?  I don't think so, at least not in principle.

fabrica will talk to deva in some way, deva will talk to the rest of the Hurd.

fabrica will also talk to the L4 kernel directly.

>   It is said that operations "in the other sense" (from user apps to
>   the driver) would be handled by virtual drivers trusted by the ddf.

I don't understand that.
 
>   I was wondering if task could just reserve one part of the thread_id
>   space for the ddf (and maybe virtual drivers threads), so that it
>   would be easy to do a check on the thread id when receiving a
>   message call, and decide if we care about this call or not.

I don't understand that either.  Who is "we" in this case?

If fabrica is a library, no external thread ids need to be checked, as
then all functions will be invoked via a function call interface.

If fabrica is a stand alone application, it only needs to check thread
ids from deva.  This can either be via a small lookup table (and the
first word in each message can be the index into the table), or, and
this imposes a little bit more policy, but could be an alternative
option that can be enabled at compile or run-time, it could check the
version field, which uniquely identifies deva in a hurd system (this
assumes only one OS is running, with multiple OSs, you would also want
to check some thread number bits for the subsystem ID).

>   If, for instance, the bus driver has to listen to incoming
>   connections from some device drivers (peter told me that in case of
>   USB, that would be the bus driver that would have to send the
>   message from the device driver), wouldn't a check on each possible
>   thread belonging to a device driver attached to the bus driver be
>   too slow?

This is an issue internal to fabrica, and common to all programs
running on L4.  The answer is no, if you are careful.  What I do in
cap-server is to send the index into a table of allowed thread ids
along with the message.  This makes lookups very fast, obviously.

You can also make a closed ipc if only one thread should be allowed.

You can use anylocalthread for local ipc.

Personally, I am not convinced in such a strong separation into many
address spaces as peter indicated he wanted to do at some time.  We
will have to see how it will work out.
 
We can reserve several version ids (and make sure no other threads
have that version id), basically extending the hurd/l4 task concept to
fabrica, if that is desired.

Well, in any case, this is the same issue for all L4 applications.  In
the Hurd, we have concepts for that, and fabrica can use the same
concepts or different ones.  But reserving thread number bits would be
pretty much overkill in my opinion (and then you would still need to
have some finer separation of some sort).

> * How would a communication between a virtual driver and the
>   real_driver be established? Would a virtual driver be something like
>   the "ddwrapper" server, or will it be something at a lower level?
> 
>   How would a virtual driver and a device driver interface?

I never heard of a distinction between virtual and real drivers before.
Is that in the docs?

> * Finally, which server would handle "enumerating available devices,
>   open devices, close them, read from them and write to them." ?

At which level?  Deva would proxy all hurd requests, but deva would
use fabrica itself for it.

Everything must go through the proxy deva.
 
> * On bootstrapping :

(I don't know about this one).

> * On the base ddf archive :
> 
>   Neal suggested that we could use the ar format to create this
>   archive. I think that something that would be pretty "cool" to have
>   would be that a user could just pickup some device drivers binaries
>   corresponding to his tastes, mix them into an archive as simply as
>   with ar and just use this to boot. (For instance, one people may
>   need some sata driver to boot, some other a scsi driver, the third a
>   network card driver and boot with nfs). So I think that it's really
>   a good idea.

I don't know where and when he suggested that, but he must have
forgotten that all the files in the archive must be page aligned for
the given architecture, if we want to be able to do a straightforward
mapping.

I have studied all the feasible (and unfeasible) formats in existance
I could think of, and none fit the bill.  This is why I decided
(lacking better options) a long time ago already that we have to use a
custom format.

Because I am extremely lazy, I settled on using "ld" with some linker
script to glue the files together.  Works pretty well, IMO, except
that I think there was no way to figure out the system's minimal page
size in a linker script.

> * On the communication between the bus drivers and the plugin manager:

(Again, don't know)

> * What should the plugin manager handle besides plug/unplug events,
>   device drivers paging? Maybe give a list of all available drivers?

(ditto)
 
> * On paging: who is w_0 and the default plugin manager pager thread?

omega 0 is something like an IRQ dispatcher, I think.

The device driver framework will have to be wired down in memory, so
no specific paging issues arise.  There needs to be some way to pin
down user contributed buffers, but that is not really paging, just the
avoidance of it.

Thanks,
Marcus