From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Grover, Andrew" Date: Fri, 12 Jan 2001 00:33:01 +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: Andrew Morton [mailto:andrewm@uow.edu.au] > > "Grover, Andrew" wrote: > > 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. > > > > Not sure I completely understand this one. > > Given that all the different bus ("resource"?) types have different > discovery mechanisms, I think you're proposing that, once discovered, > they will be recorded in a database of some form? In a > unified format? While different buses have different discovery mechanisms, they all will either result in either device removal or device insertion notifications. Since we will want to have one hotplug module loader (yes?) it seems necessary that the various bus enumerators communicate with it in a common format. Having the loading entity keep track of what devices/drivers are already present would then have two advantages: 1) Bus enumeration drivers can, when queried, report all devices found, and do not have to worry about which ones have come or gone, because the manager is keeping track. 2) Because we know the entire device attachment tree, when suspending, we can send power-down requests outermost-first and vice-versa when resuming. > So we have, if you like, an array of objects each of which represents > a device in the system, and they each have state, `eject', > `powerdown' methods, > etc? I think so. But perhaps the appropriate structure is a tree, because devices depend on each other and we will need to sequence power transitions with that in mind. (e.g. don't turn off the PCI bus until all PCI devices are powered down.) > > Heh. XircomNic is-a CardbusDevice is-a PCIDevice is-a Device > is-a blah. > > It could get complex with devices behind bridges behind bridges. Is a > bridge a device? Do we need to care about bridges? Yes, it can get complex, but I think we do need to account for bridges. Regards -- Andy _______________________________________________ Linux-hotplug-devel mailing list Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel