On Tue, 27 Dec 2005, Dmitry Torokhov wrote:

On 12/27/05, Patrick Mochel [off-list ref] wrote:

quoted

Would it be possible to simply mark the device as 'removed' and ignore it
until we resumed, and then clean it up (hotplug events and everything)?

Unfortunately swsusp resumes devices in the middle of suspend process
with everything frozen and drivers don't know if they may clean up or
have to postpone doing so. To do it uniformly you'd need to introduce
threads and offload cleanups. I doubt it is good idea to require each
subsystem to define cleanup thread or [ab]used keventd?

Blech, I forgot about the caveman-like way of making sure the swap device
is resumed. :)

Nevertheless, it shouldn't matter, and you bring up a point that exists,
and is actually more prevalent - the case of trying to resume a device
that doesn't exist any more.

Last week, I suggested that all devices that are thought to be present
should be resumed. Those that have gone away should be removed once the
system is resumed, then new devices should be discovered. In this, I am
implying that devices that are thought to be there, but really aren't
(have been removed, unplugged, or undocked) should be marked as such
(somehow) and taken care of later.

When swsusp resumes every device before writing the image, it should
ignore devices that aren't present anymore. They can still exist in
software (in the various object hiearchies), but they should just be
skipped. Ditto for when we 'suspend' them again, and on the real resume.

When the system is back up and userspace is started again, something
should walk the device tree and reap the devices that are no longer
present. The core could do this, so long as the flag was in struct device,
though I'm not sure that it would know about the hooks to trigger a
removal on the device's bus (or would it need to?). Then, we can free all
the memory, do all the unregistering, and generate all the hotplug events.

Of course, at that point, we'll need to discover any new devices, which is
going to be bus-speciifc. But, with a few extra bits of infrastructure
(per-bus objects, and a ->scan() method in struct bus_type), this will
relatively simple..

Thoughts?


	Patrick