From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: linux-pm@lists.osdl.org
Subject: Re: Re: Hotplug events during sleep transition
Date: Wed, 28 Dec 2005 11:59:14 +0100 [thread overview]
Message-ID: <200512281159.14645.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.50.0512272026140.6491-100000@monsoon.he.net>
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Hi,
On Wednesday, 28 December 2005 05:36, Patrick Mochel wrote:
>
> On Tue, 27 Dec 2005, Dmitry Torokhov wrote:
>
> > On 12/27/05, Patrick Mochel <mochel@digitalimplant.org> wrote:
>
> > > 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?
I think for a (suspended) device that can be removed, unplugged, undocked,
etc. (call it "removable") the most natural place in which we can detect
that the device is no longer accessible is the device driver's .resume()
routine, at least as far as swsusp is concerned.
IMO .resume() should check if the device is still there and if not, it should
put the device on a list of "no-longer-present devices" and just return.
After the .resume() routines of all devices have completed, the list can
be processed by something (a kernel thread?) that will do the changes
on whatever level is necessary.
Greetings,
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-12-28 10:59 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 14:28 Hotplug events during sleep transition Alan Stern
2005-12-22 14:34 ` Pavel Machek
2005-12-22 18:20 ` Dmitry Torokhov
2005-12-22 20:52 ` Patrick Mochel
2005-12-22 20:56 ` Randy.Dunlap
2005-12-22 22:13 ` Alan Stern
2005-12-23 3:49 ` Patrick Mochel
2005-12-23 3:52 ` Dmitry Torokhov
2005-12-23 15:20 ` Alan Stern
2005-12-23 15:35 ` Patrick Mochel
2005-12-23 16:52 ` Alan Stern
2005-12-23 17:20 ` Pavel Machek
2005-12-23 21:22 ` Alan Stern
2005-12-23 21:28 ` Greg KH
2005-12-23 22:09 ` Nigel Cunningham
2005-12-23 22:31 ` Pavel Machek
2005-12-23 22:40 ` Nigel Cunningham
2005-12-23 22:48 ` Pavel Machek
2005-12-23 22:57 ` Nigel Cunningham
2005-12-24 0:29 ` Nigel Cunningham
2005-12-24 15:11 ` Alan Stern
2005-12-24 15:28 ` Pavel Machek
2005-12-24 17:02 ` Greg KH
2005-12-23 21:28 ` Pavel Machek
2005-12-23 19:40 ` Greg KH
2005-12-24 0:23 ` Patrick Mochel
2005-12-25 2:56 ` Alan Stern
2005-12-25 8:53 ` Pavel Machek
2005-12-25 16:43 ` Alan Stern
2005-12-25 16:52 ` Dmitry Torokhov
2005-12-25 19:54 ` Pavel Machek
2005-12-25 19:52 ` Pavel Machek
2005-12-26 3:53 ` Alan Stern
2005-12-26 21:20 ` Patrick Mochel
2005-12-26 22:50 ` Dmitry Torokhov
2005-12-26 23:01 ` Alan Stern
2005-12-27 21:45 ` Dmitry Torokhov
2005-12-27 22:08 ` Pavel Machek
2005-12-27 22:21 ` Dmitry Torokhov
2005-12-27 22:31 ` Pavel Machek
2005-12-27 22:39 ` Dmitry Torokhov
2005-12-27 22:44 ` Pavel Machek
2005-12-29 2:07 ` Alan Stern
2005-12-27 21:09 ` Patrick Mochel
2005-12-27 21:51 ` Dmitry Torokhov
2005-12-28 4:36 ` Patrick Mochel
2005-12-28 6:11 ` Dmitry Torokhov
2005-12-28 10:59 ` Rafael J. Wysocki [this message]
2005-12-29 2:18 ` Alan Stern
2005-12-29 2:55 ` Nigel Cunningham
2005-12-29 11:29 ` Rafael J. Wysocki
2005-12-30 17:46 ` Alan Stern
2006-01-04 23:31 ` Pavel Machek
2006-01-05 16:07 ` Alan Stern
2006-01-05 19:05 ` Pavel Machek
2005-12-29 2:13 ` Alan Stern
2005-12-29 2:10 ` Alan Stern
2005-12-29 5:20 ` Dmitry Torokhov
2005-12-30 18:26 ` Alan Stern
2005-12-30 19:18 ` Dmitry Torokhov
2005-12-30 19:26 ` Alan Stern
2005-12-30 19:42 ` Dmitry Torokhov
2005-12-30 20:13 ` Alan Stern
2005-12-29 2:02 ` Alan Stern
2005-12-30 18:34 ` Patrick Mochel
2005-12-30 19:21 ` Alan Stern
2006-01-02 23:49 ` Patrick Mochel
2005-12-26 23:25 ` Alan Stern
2005-12-23 18:32 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200512281159.14645.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox