Re: Questions about the device driver framework

[Matthieu Lemerre]

Marcus Brinkmann <address@hidden> writes:

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

OK, that is what I was first thinking. I think I was confused by the
virtual drivers stuff.

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

It was any receiver thread part of the device driver framework.

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

I didn't even thought about passing index of the lookup table in the
message.

Your second technique was actually what I was thinking about when
talking about "reserving a thread_id space", but I wanted to be
general (but I was in fact too vague) because I believed that the ddf
should be used by other OSes than the Hurd, which may have other
thread allocation policies than the Hurd.

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

OK, I have read the corresponding code.

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

I thought this was already discussed in fact, as well as the fact that
fabrica was a stand-alone server.

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

In fact I only suggested to reserve some thread ids, either by the
version number or with the thread number without really thinking about
it.

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

Absolutely.

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

OK, pretty much what I was thinking at first.
>
>> * 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.
>

If you want me too, maybe can I write a tool which would create this
archive, and a corresponding library to extract it from deva.

  
>> * On paging: who is w_0 and the default plugin manager pager thread?
>
> omega 0 is something like an IRQ dispatcher, I think.

That's what is said in the doc.

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

Thank you for all these explanations,

Matthieu