Re: hotplug TTD

[David Brownell <david-b@pacbell.net>]

> From: Grover, Andrew <andrew.grover@intel.com>
> Sent: Tuesday, January 09, 2001 10:34 PM
>
> Is it unreasonable, long-term, to move towards a unified Linux hotplug
> architecture?

I don't see why it would be unreasonable.  Arguably, that's the direction
that has been set already.  But -- what do you mean by "architecture"?
That's a loaded word in many minds.

So far I've been happy to start seeing subsystems share more structure and
start to behave in the same kinds of ways.  I think there's a long way we
can usefuly go down that path.  "Lightweight architecture"?  The design
patterns used by various subsystems need to fit together effectively.


> Under both Windows and BeOS, a given bus driver is responsible for
> enumerating the devices on it, and it tells a central "configuration
> manager", who then is the one who loads the drivers.

Many of us don't know those two systems very well; but perhaps the
"/sbin/hotplug" policy agent is analagous to that mananager.  Except
that it can't just "load drivers", it's got to configure them too.
Maybe you could elaborate a bit?

Using USB and PCI (in Linux 2.4 kernels) as an example, clearly the
bus drivers (USB HCDs, Cardbus or Hotplug PCI bridges) are going to
enumerate devices and handle some of the config change details.  But
the goal is to punt all the hard policy questions (what driver, how
to set it up) to userspace through one mechanism (/sbin/hotplug).


> Having one entity who knows about all devices on a system is also great for
> power management, and implementing suspend-to-memory and suspend-to-disk.

I'm glad you mentioned power management, the "hot" in "hot plug"!

USB has some work to do yet for power management.  For example, I
suspect that USB Host Controller Drivers ("HCDs") should mediate
suspend/resume processing for each of their devices, ensuring devices
get suspended before bridges (and resumed after).  That's simple
enough to do (Cardbus got complicated because of PCMCIA) but it calls
for "struct usb_driver" API updates.

So far I've been thinking of power management as _mostly_ an issue
that subsystems should deal with locally ... following global rules
and policies.  Likely you have clearer ideas about how those should
get reflected down to the subsystems, or back to some global/central
entity when policy questions arise.

- Dave




_______________________________________________
Linux-hotplug-devel mailing list
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel