[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: drivers for l4 (2)
Peter De Schrijver
Re: drivers for l4 (2)
Wed, 2 Apr 2003 20:25:18 +0200
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
> 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
> - the driver which should handle the device is determined. It can be matched
> 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.