Re: drivers for l4 (2)

[Peter De Schrijver]

On Wed, Mar 26, 2003 at 11:53:16AM +0100, Michal 'hramrach' Suchanek wrote:
> 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.

I don't think loading should be handled by the busdriver. This would duplicate
the logic of choosing the AS and loading the driver to all busdrivers. I think
it is better this functionality is centralised in 1 server. 

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

That would be something to be handled by the hotplug server as well.

Cheers,

p2.