Re: drivers for l4 (2)

[Michal 'hramrach' Suchanek]

On Wed, Apr 02, 2003 at 08:25:18PM +0200, Peter De Schrijver wrote:
> 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 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. 
What logic? Logic about what is done is in a configuration manager and logic
about how it is done is in the exec server. It may be that
"driver exec server" == "hotplug manager".
> 
> > 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.

That looks like centralizing something that should be split imho. 
Any bus driver needs to know all its devices and their coming and going anyway, 
there should not be much trouble exporting the knowledge to the outside world.
And it has to be done anyway, whether the information is collected in hotplug
manager or somewhere else.
On the other hand, the server loading the drivers into memory should know
them by address space and not neccessarily by the bus on which their device
is located or device class.