All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: Re: Hotplug events during sleep transition
Date: Wed, 28 Dec 2005 01:11:28 -0500	[thread overview]
Message-ID: <200512280111.29000.dtor_core@ameritech.net> (raw)
In-Reply-To: <Pine.LNX.4.50.0512272026140.6491-100000@monsoon.he.net>

On Tuesday 27 December 2005 23: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 suppose... New devices will indeed have to be bus-specific but reaping
function I think can be same for everyone - just call device_unregister()
for every device that is marked as 'dead'. Unregister usually ignores all
errors anyway.

-- 
Dmitry

  reply	other threads:[~2005-12-28  6:11 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 [this message]
2005-12-28 10:59                                 ` Rafael J. Wysocki
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=200512280111.29000.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=linux-pm@lists.osdl.org \
    --cc=mochel@digitalimplant.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.