Re: drivers for l4 (2)

[Michal 'hramrach' Suchanek]

On Mon, Mar 24, 2003 at 12:21:19PM +0100, Daniel Wagner wrote:
> 
> + The hotplug manager implements the following API:
>       + add device: Announces a new device in the system.             
>       + remove device: Device has gone
> 
> The hotplug manager will load the appropriate device driver into one of the 
> device driver AS's. The hotplug manager create or deletes these AS's as
> necessary. Whithin each AS a device driver management thread runs which 
> handles
> the loading and unloading of the drivers.
I do not understand the role of hotplug manager. Is it supposed to be a special
exec server for drivers?
I can think of four things that are needed when a device is to be configured:
- the device is discovered by a bus driver (or is configured for a non-pnp bus
  somehow)
- the driver which should handle the device is determined. It can be matched by
  some device IDs on using some driver tables or read from the fixed
  configuration of non-pnp device
- it should de determined whether the driver should be loaded immediately or
  when the device is first accessed
- the driver is loaded and executed

I can imagine that there could be a configuration manager that stores the
neccessary information like device ID tables, non-pnp device tables and some 
configuration (ie which device (class) is enabled automagically, on demand
or never).

I think there is no need for a special hotplug manager. The loading of device
drivers could be done by bus drivers (that is read configuration from
somewhere and have the driver loaded by an exec server when needed).
If some process would like to know when a device is discovered or configured
it could register with the bus driver.
For a more convenient interface there could be a server that walks the device
tree and registers with all buses to provide events filters.
ie. X server or some mouse driver would like to receive HID device
(de)configuration events on any bus, a file manager or automounter would
like to know when block devices are (de)configured
It could provide a "replay" function which would send events for all currently
known devices as if they were just configured.

> 
> Device drivers themselves are modules which are relocateable so they can be 
> loaded anywhere into the AS. This can be done by building them as Position 
> Independent Code or having explicit relocation tables. The latter is probably 
> the best choice, except if we would load a driver multiple times for multiple
> devices of the same type. They are loaded and started by the management 
> thread.
> They also get a reference to a port of their parent bus manager so they can
> ask for resources, etc.
>