From: "Nigel Cunningham" <ncunningham@linuxmail.org>
To: Todd Poynor <tpoynor@mvista.com>,
Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Patrick Mochel <mochel@digitalimplant.org>,
linux-hotplug-devel@lists.sourceforge.net,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Sat, 01 May 2004 00:03:26 +0000 [thread overview]
Message-ID: <opr7anr02fshwjtr@laptop-linux.wpcb.org.au> (raw)
In-Reply-To: <4092B02C.5090205@mvista.com>
Hi.
Sorry for getting in on this conversion a little late; I've only just
noticed it.
The usual way in which userspace notification of suspending/resuming is
handled at the moment is via scripts which are run prior to suspending and
after resuming. As has been noted, the first thing the kernel side
implementations does is freeze userspace, keeping things static until post
resume. This seems to me to be a good, simple model. DHCP releases can be
handled from user space, prior to echo 4 > /proc/acpi/sleep (or
alternatives) and the whole difficulty regarding interactions between
userspace and kernelspace just goes away.
Note too that the actual invocation of a suspend can still be in response
to kernel events. An ACPI event can be sent to the userspace ACPI daemon,
which does userspace preparations and then invokes the kernel suspend
mechanism. After resume, it can also do userspace reinitialisation.
Given this model, I would suggest that hotplug should silently drop any
events that happen while suspending, and queue events that occur while
resuming until the kernelspace part of resuming is complete and userspace
can run as normal. It shouldn't rely upon device suspend/resume
notifications because they can and do happen while we're still in the
process of suspending and resuming. The means to detect whether we're
suspending or resuming or running normally could be implemented as a
simple function that could test the status of the different suspend
implementations.
Is that at all helpful?
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614, Australia.
+61 (2) 6251 7727 (wk)
At just the right time, while we were still powerless, Christ
died for the ungodly. (Romans 5:6)
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-05-01 0:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040429202654.GA9971@dhcp193.mvista.com>
2004-04-29 21:42 ` [PATCH] Hotplug for device power state changes Russell King
2004-04-29 22:36 ` Todd Poynor
2004-04-30 0:50 ` Benjamin Herrenschmidt
2004-04-30 8:30 ` Russell King
2004-04-30 19:59 ` Todd Poynor
2004-04-30 21:56 ` Greg KH
2004-05-01 1:16 ` Todd Poynor
2004-05-01 1:48 ` Greg KH
2004-05-03 21:33 ` Todd Poynor
2004-05-01 0:03 ` Nigel Cunningham [this message]
2004-05-03 22:04 ` Todd Poynor
2004-04-30 19:07 ` Todd Poynor
2004-05-15 1:40 ` Nicolas Pitre
2004-05-15 23:34 ` Pavel Machek
[not found] ` <Pine.LNX.4.50.0405040819490.3562-100000@monsoon.he.net>
2004-05-04 20:36 ` Todd Poynor
[not found] ` <Pine.LNX.4.50.0405042110440.30304-100000@monsoon.he.net>
2004-05-06 1:08 ` Todd Poynor
2004-05-14 2:50 ` Pavel Machek
2004-05-15 2:08 ` Todd Poynor
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=opr7anr02fshwjtr@laptop-linux.wpcb.org.au \
--to=ncunningham@linuxmail.org \
--cc=benh@kernel.crashing.org \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=tpoynor@mvista.com \
/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;
as well as URLs for NNTP newsgroup(s).