From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Greg KH <greg@kroah.com>,
mochel@digitalimplant.org,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: Hotplug events for system suspend/resume
Date: Wed, 12 May 2004 03:59:50 +0000 [thread overview]
Message-ID: <200405121359.50899.ncunningham@linuxmail.org> (raw)
In-Reply-To: <40A18F94.4000607@mvista.com>
Hi.
On Wed, 12 May 2004 12:44, Todd Poynor wrote:
> The patch hooks into the power subsystem prior to freezing processes and
> after unfreezing processes, so I don't think it's a concern (unless
> something is using the power subsystem rather oddly). This patch sends
> a single notification of system suspend and a single notification of
> system resume, in case there's any confusion with the individual device
> state change notifiers also recently discussed. It's been run
> successfully on one ACPI system and one non-ACPI system.
Great.
> > In my mind, this approach is simpler and makes more sense: userspace
> > should worry about userspace actions related to suspending before calling
> > kernelspace. Kernel space should then only worry about saving and
> > restoring driver states and should be transparent to user space. ...
>
> Agreed, with the minor reservations listed in a previous email (suspend
> initiated by drivers must coordinate ad-hoc with userspace, etc.).
You're thinking ACPI drivers initiating a suspend? They would do it through
acpid, wouldn't they? At least that's the glue I use to get my sleep button
to initiate a suspend. I would assume thermal events would/should work the
same.
> I'll let anybody who cares more deeply about this speak up now,
> otherwise this isn't a battle I'll be fighting on behalf of others any
> more. Thanks -- Todd
:> I wasn't meaning to make it a battle!
Nigel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
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
WARNING: multiple messages have this Message-ID (diff)
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Greg KH <greg@kroah.com>,
mochel@digitalimplant.org,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: Hotplug events for system suspend/resume
Date: Wed, 12 May 2004 13:59:50 +1000 [thread overview]
Message-ID: <200405121359.50899.ncunningham@linuxmail.org> (raw)
In-Reply-To: <40A18F94.4000607@mvista.com>
Hi.
On Wed, 12 May 2004 12:44, Todd Poynor wrote:
> The patch hooks into the power subsystem prior to freezing processes and
> after unfreezing processes, so I don't think it's a concern (unless
> something is using the power subsystem rather oddly). This patch sends
> a single notification of system suspend and a single notification of
> system resume, in case there's any confusion with the individual device
> state change notifiers also recently discussed. It's been run
> successfully on one ACPI system and one non-ACPI system.
Great.
> > In my mind, this approach is simpler and makes more sense: userspace
> > should worry about userspace actions related to suspending before calling
> > kernelspace. Kernel space should then only worry about saving and
> > restoring driver states and should be transparent to user space. ...
>
> Agreed, with the minor reservations listed in a previous email (suspend
> initiated by drivers must coordinate ad-hoc with userspace, etc.).
You're thinking ACPI drivers initiating a suspend? They would do it through
acpid, wouldn't they? At least that's the glue I use to get my sleep button
to initiate a suspend. I would assume thermal events would/should work the
same.
> I'll let anybody who cares more deeply about this speak up now,
> otherwise this isn't a battle I'll be fighting on behalf of others any
> more. Thanks -- Todd
:> I wasn't meaning to make it a battle!
Nigel
next prev parent reply other threads:[~2004-05-12 3:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-11 1:00 Hotplug events for system suspend/resume Todd Poynor
2004-05-11 23:00 ` Greg KH
2004-05-11 23:00 ` Greg KH
2004-05-12 0:39 ` Todd Poynor
2004-05-12 0:39 ` Todd Poynor
2004-05-12 2:16 ` Nigel Cunningham
2004-05-12 2:16 ` Nigel Cunningham
2004-05-12 2:44 ` Todd Poynor
2004-05-12 2:44 ` Todd Poynor
2004-05-12 3:59 ` Nigel Cunningham [this message]
2004-05-12 3:59 ` Nigel Cunningham
2004-05-12 19:36 ` Todd Poynor
2004-05-12 19:36 ` Todd Poynor
2004-05-15 3:03 ` Pavel Machek
2004-05-15 3:03 ` Pavel Machek
2004-05-12 15:08 ` Greg KH
2004-05-12 15:08 ` Greg KH
2004-05-13 22:46 ` Tim Bird
2004-05-13 22:46 ` Tim Bird
2004-05-13 23:28 ` Greg KH
2004-05-13 23:28 ` Greg KH
2004-05-15 2:59 ` Pavel Machek
2004-05-15 2:59 ` Pavel Machek
2004-05-12 18:52 ` Grover, Andrew
2004-05-12 18:52 ` Grover, Andrew
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=200405121359.50899.ncunningham@linuxmail.org \
--to=ncunningham@linuxmail.org \
--cc=greg@kroah.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--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 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.