RE: hotplug TTD

["Grover, Andrew" <andrew.grover@intel.com>]

> From: David Brownell [mailto:david-b@pacbell.net]

> > From: Grover, Andrew <andrew.grover@intel.com>
> > 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.

I mean we have individual subsystems doing HP all over the place. While each
has bus-specific stuff, a lot of the stuff is the same across all of these.

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

Well, of course devices need to be configured, but in my mind once we've
loaded the driver that's half the battle. If I insert a USB foo device, the
foo driver is going to be the one who knows how to configure it, yes? And, I
remember reading that the latest modutils had some mechanism to pass config
info, but I haven't looked further..

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

True, some setup info is surely needed. But one of the goals of hotplug is
you insert the device and it "just works". Won't that be awesome?? ;-)

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

I agree, a given subsystem driver is in a much better position to power
manage itself instead of a global entity. But I also think the system needs
be able to veto a subsystem's PM in light of the system's overall state.

For example, in Windows, a driver can request to be put into a power state.
If the system has no objections, it turns around and tells the driver to
switch states. This has two advantages: 1) it gives the OS the chance to not
fulfill the request (if it knows turning off the device would have bad
consequences) and 2) it lets the OS implement a simple PM strategy, that can
then be overridden by the subsystem if it wishes. This saves each driver
from worrying about PM policy if the OS's default policy is good enough.

Regards -- Andy


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