RE: hotplug TTD

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

> 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