From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Grover, Andrew" Date: Fri, 12 Jan 2001 01:13:47 +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: David Brownell [mailto:david-b@pacbell.net] > > From: Grover, Andrew > > 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