From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 11 Jan 2001 16:10:45 +0000 Subject: Re: hotplug TTD Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > From: Grover, Andrew > 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