[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: drivers for l4-hurd

From: Michal 'hramrach' Suchanek
Subject: Re: drivers for l4-hurd
Date: Wed, 27 Nov 2002 15:30:46 +0100
User-agent: Mutt/1.4i

On Wed, Nov 27, 2002 at 12:40:10PM +0100, J?rg Sonnenberger wrote:
> On Tue, 26 Nov 2002 22:24:10 +0100
> Daniel Wagner <address@hidden> wrote:
> > Configure client device drivers
> >      The bus driver should start the appropriate   client device driver
> >      translator when an insertion event is detected. It   should also
> >      provide the client device driver with all necessary
> >      configuration info, so it can access the device it needs. This
> >      configuration   data typically consists of the bus addresses of
> >      the device and possibly IRQ   numbers or DMA channel ID's.
> I don't like the idea of a bus driver starting the client drivers 
> automatically.
> This would include too much policy in the bus driver. E.g. I don't want
> the network adapter running when my notebook is on battery. Perhaps the bus 
> driver
> sends this insertion events to device management server, which handles the 
> load of

Imho the translators should be configured passively so that they are started
when the device is needed.

ie a network translator such as /servers/hardware/network/en0 would be
a passive translator. The translator would be configured either to attach to
a particular device (such as /servers/hardware/pci0/somenumber:othernumber) or
search for a compatible device in some places (such as /servers/hardware/pci?/)
or contact a server that does the add/removal bookkeeping
(ie /servers/hardware/manager) to see if it knows about a compatible device.

But in any case the ethernet translator is not started unless the device is
opened. If the ethernet card was on some more exotic bus like cardbus or usb 
the bus itself might be inactive at the time the ethernet device is opened and
would be activated by the ethernet driver.

I think that having a central management server is just moving the policy from
bus to that server which doesn't look any better.

Anyway the device tree should start somewhere and when you want to change
the power state you can just tell the top level translator which should
forward the change down the tree. The translator does know that it has some
open devices.

For example, there can be arbitrary number of power saving levels. Each device
should be configured to map these levels to some of the possible device states.
(ie 0=on, 1=saving, 2=suspend, 3=off)
When power saving level N is entered the device should enter
a saving state corresponding to nearest higher level. A bus should notify all
devices and enter a state which is minimum of its own state corresponding to
level N and the states of all connected devices.
Configuring a bus like level0->on, level_max->off would make it power off if
there are no devices open on it and any power savings are attempted.

The change notifications should be easily registered with particular
bus driver. This way there could be something like /servers/hardware/usbhotplug
which would be frobbed by a startup script. It would frob all usb busses and
register hotplug notifications on them.
Then it can do anything it likes when new device appears.

Michal Suchanek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]