Questions about the device driver framework

[Matthieu Lemerre]

Hi everybody,

  I have a few comments and questions on the device-drivers part of
  the hurd-on-l4 document:


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

  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?

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


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


* On bootstrapping :

  It is said that : "If new drivers are available it has to inform the
  plugin manager to ask for unresolved drivers again."

  I don't know if it is possible, but won't it be better if all
  drivers could respond to a "stop" rpc, and we could then revoke all
  the mapping to that driver when it answered (or we may also kill it),
  and plug a new driver instead. I think this can easily be done by the
  plugin manager which is the device driver's pager.

  For instance, we could put in our archive a generic ide driver, but
  we could replace it after by a specific driver controller. 

  We could send this "stop" rpc to all drivers which would have to be
  replaced just before asking for this reprobe.

  Of course, a power user could put the good driver directly in the
  initial device driver archive.


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


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

  Why would they pass through the bus driver? Wouldn't it be more
  simpler if each bus driver directly had some sort of capability on
  the plugin manager, so that it could directly send to it notify
  events? The capability sytem does not seems to be hard, since
  thread_id will be mostly fixed I think.


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

 Since plug/unplug events can be very differents depending on the bus
 type, I think that the interfaces could match these:

-plugman_load_driver (bus_type,...) #the actual number of arguments
depend on the bus type. There can be: (as peter said: for PCI I would
say : vendor id, device id, subsystem vendor id and device id, class,
and slot (those numbers you see in lspci))

-plugman_unload_driver (bus_type,...) #the contrary, that should contain
enough informations to remove the adequate driver from the memory.

We would have to specify the interface for each bus type.

* On paging: who is w_0 and the default plugin manager pager thread?


OK, that's already a big amount of questions :)

Thank you,
Matthieu