Hi!
Init should get to know that user pressed power button (so it can do
shutdown and poweroff). Plus, it is nice to let user know that we can
read such event. [I hunted bug for few hours, thinking that kernel
does not get the event at all].
Here's patch to do that. Please apply,
Pavel
diff -urb -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/events/evevent.c linux/drivers/acpi/events/evevent.c
--- clean/drivers/acpi/events/evevent.c Sun Apr 1 00:22:57 2001
+++ linux/drivers/acpi/events/evevent.c Wed Apr 4 01:08:11 2001
@@ -30,6 +30,8 @@
#include "acnamesp.h"
#include "accommon.h"
+#include <linux/signal.h>
+
#define _COMPONENT EVENT_HANDLING
MODULE_NAME ("evevent")
@@ -197,14 +172,18 @@
if ((status_register & ACPI_STATUS_POWER_BUTTON) &&
(enable_register & ACPI_ENABLE_POWER_BUTTON))
{
+ printk ("acpi: Power button pressed!\n");
+ kill_proc (1, SIGTERM, 1);
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_POWER_BUTTON);
}
+
/* sleep button event */
if ((status_register & ACPI_STATUS_SLEEP_BUTTON) &&
(enable_register & ACPI_ENABLE_SLEEP_BUTTON))
{
+ printk("acpi: Sleep button pressed!\n");
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_SLEEP_BUTTON);
}
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
This is not correct, because we want the power button to be configurable.
The user should be able to redefine the power button's action, perhaps to
only sleep the system. We currently surface button events to acpid, which
then can do the right thing, including a shutdown -h now (which I assume
notifies init).
Regards -- Andy
> From: Pavel Machek [mailto:[email protected]]
> Init should get to know that user pressed power button (so it can do
> shutdown and poweroff). Plus, it is nice to let user know that we can
> read such event. [I hunted bug for few hours, thinking that kernel
> does not get the event at all].
>
> Here's patch to do that. Please apply,
> Pavel
>
> diff -urb -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS*
> -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x
> System.map -x autoconf.h -x compile.h -x version.h -x
> .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?*
> -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build
> -x build -x configure -x *target* -x *.flags -x *.bak
> clean/drivers/acpi/events/evevent.c
> linux/drivers/acpi/events/evevent.c
> --- clean/drivers/acpi/events/evevent.c Sun Apr 1 00:22:57 2001
> +++ linux/drivers/acpi/events/evevent.c Wed Apr 4 01:08:11 2001
> @@ -30,6 +30,8 @@
> #include "acnamesp.h"
> #include "accommon.h"
>
> +#include <linux/signal.h>
> +
> #define _COMPONENT EVENT_HANDLING
> MODULE_NAME ("evevent")
>
> @@ -197,14 +172,18 @@
> if ((status_register & ACPI_STATUS_POWER_BUTTON) &&
> (enable_register & ACPI_ENABLE_POWER_BUTTON))
> {
> + printk ("acpi: Power button pressed!\n");
> + kill_proc (1, SIGTERM, 1);
> int_status |= acpi_ev_fixed_event_dispatch
> (ACPI_EVENT_POWER_BUTTON);
> }
>
> +
> /* sleep button event */
>
> if ((status_register & ACPI_STATUS_SLEEP_BUTTON) &&
> (enable_register & ACPI_ENABLE_SLEEP_BUTTON))
> {
> + printk("acpi: Sleep button pressed!\n");
> int_status |= acpi_ev_fixed_event_dispatch
> (ACPI_EVENT_SLEEP_BUTTON);
> }
>
>
> --
> I'm [email protected]. "In my country we have almost anarchy and I
> don't care."
> Panos Katsaloulis describing me w.r.t. patents at
> [email protected]
>
In article <[email protected]>,
Pavel Machek <[email protected]> wrote:
>Hi!
>
>Init should get to know that user pressed power button (so it can do
>shutdown and poweroff). Plus, it is nice to let user know that we can
>read such event. [I hunted bug for few hours, thinking that kernel
>does not get the event at all].
>
>Here's patch to do that. Please apply,
Not so hasty ;)
>+ printk ("acpi: Power button pressed!\n");
>+ kill_proc (1, SIGTERM, 1);
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
good reason; on some (many?) systems, the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to happen.
Perhaps SIGUSR1 ?
Mike.
In article <[email protected]>,
Miquel van Smoorenburg <[email protected]> wrote:
>SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
>good reason; on some (many?) systems, the shutdown scripts
>include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
>"all processes except me". That means init will get hit with
>SIGTERM occasionally during shutdown, and that might cause
>weird things to happen.
>
>Perhaps SIGUSR1 ?
In the immortal words of Max Headroom, t-t-talking to myself ;)
In fact, the kernel should probably use a real-time signal
with si_code set to 1 for ctrl-alt-del, 2 for the powerbutton etc.
It should first check if process 1 (init) installed a handler
for that real-time signal. If not, it should use the old
signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest).
Mike.
On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
>
> the shutdown scripts
> include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> "all processes except me". That means init will get hit with
> SIGTERM occasionally during shutdown, and that might cause
> weird things to happen.
-1 mean everything but init.
>From the manpage:
If pid equals -1, then sig is sent to every process except
for the first one, from higher numbers in the process
table to lower.
And later:
BUGS
It is impossible to send a signal to task number one, the
init process, for which it has not installed a signal han-
dler. This is done to assure the system is not brought
down accidentally.
Kurt
On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
> In article <[email protected]>,
> Pavel Machek <[email protected]> wrote:
> >Init should get to know that user pressed power button (so it can do
> >shutdown and poweroff). Plus, it is nice to let user know that we can
>
> Not so hasty ;)
>
> >+ printk ("acpi: Power button pressed!\n");
> >+ kill_proc (1, SIGTERM, 1);
[reasons deleted]
Is using a signal the appropriate thing to do anyway?
Wouldn't there be better solutions?
Perhaps a mechanism a user space program can use to communicate to the kernel
(ala arpd/kerneld message queues, or something like klogd). Then a more
general user space tool could be used that would do policy appropriate
stuff, ending with init 0.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[email protected] and be right all the time, or not work at all
http://www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything but init.
Oh, maybe you mean killall5 -TERM?
Which would send a SIGTERM to all processes but the one in his
own session.
(Hey look, you wrote that manpage.)
Kurt
According to Kurt Roeckx:
> On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
> > The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything but init.
>
> From the manpage:
Oh. OK, so this is yet another special case for init - forget to
check those. Sorry about that (hey it's 01:53 here, I should be
in bed). Yet I still think it'd be a better idea to use RT signals,
see my other message in this thread.
Mike.
On Tue, Apr 10, 2001 at 10:05:13AM -0700, Grover, Andrew wrote:
> This is not correct, because we want the power button to be configurable.
> The user should be able to redefine the power button's action, perhaps to
> only sleep the system. We currently surface button events to acpid, which
> then can do the right thing, including a shutdown -h now (which I assume
> notifies init).
Just today a friend saw my box shutdown via the powerbutton and
wondered if he coudln't set his up to trigger a different event
(actually two: he wanted his sister - the guilty party - zapped,
and a webcam shot of her face to prove it)...
--
John Lenton ([email protected]) -- Random fortune:
?Como meter?n los cacahuetes dentro de la c?scara?
Kurt Roeckx <[email protected]> on 04/11/2001 06:16:52 AM
To: Miquel van Smoorenburg <[email protected]>
cc: [email protected] (bcc: Amol Lad/HSS)
Subject: Re: Let init know user wants to shutdown
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything but init.
>>> well. don't fight.. here is something from kernel/signal.c
asmlinkage int sys_kill(int pid, int sig){
...
...
return kill_something_info(sig,&info,pid)
}
int
kill_something_info(int sig, struct siginfo *info, int pid){
...
...
...
if (pid == -1){
for_each_task(p){(int
if (p->pid >1 && p != current){
err = send_sig_info(sig,info,p);
...
...
}
}
}
Amol
Oh, maybe you mean killall5 -TERM?
Which would send a SIGTERM to all processes but the one in his
own session.
(Hey look, you wrote that manpage.)
Kurt
Hi!
> This is not correct, because we want the power button to be configurable.
> The user should be able to redefine the power button's action, perhaps to
> only sleep the system. We currently surface button events to acpid, which
> then can do the right thing, including a shutdown -h now (which I assume
> notifies init).
There's no problem with configurability -- you can configure init as
well. I saw it pretty much analogic to situation with Ctrl-Alt-Del: it
also sends signal to init. Init then decides what to do. [I believe
requiring acpid for such easy stuff is not neccessary...]
Pavel
> Regards -- Andy
>
> > From: Pavel Machek [mailto:[email protected]]
> > Init should get to know that user pressed power button (so it can do
> > shutdown and poweroff). Plus, it is nice to let user know that we can
> > read such event. [I hunted bug for few hours, thinking that kernel
> > does not get the event at all].
> >
> > Here's patch to do that. Please apply,
> > Pavel
> >
> > diff -urb -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS*
> > -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x
> > System.map -x autoconf.h -x compile.h -x version.h -x
> > .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?*
> > -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build
> > -x build -x configure -x *target* -x *.flags -x *.bak
> > clean/drivers/acpi/events/evevent.c
> > linux/drivers/acpi/events/evevent.c
> > --- clean/drivers/acpi/events/evevent.c Sun Apr 1 00:22:57 2001
> > +++ linux/drivers/acpi/events/evevent.c Wed Apr 4 01:08:11 2001
> > @@ -30,6 +30,8 @@
> > #include "acnamesp.h"
> > #include "accommon.h"
> >
> > +#include <linux/signal.h>
> > +
> > #define _COMPONENT EVENT_HANDLING
> > MODULE_NAME ("evevent")
> >
> > @@ -197,14 +172,18 @@
> > if ((status_register & ACPI_STATUS_POWER_BUTTON) &&
> > (enable_register & ACPI_ENABLE_POWER_BUTTON))
> > {
> > + printk ("acpi: Power button pressed!\n");
> > + kill_proc (1, SIGTERM, 1);
> > int_status |= acpi_ev_fixed_event_dispatch
> > (ACPI_EVENT_POWER_BUTTON);
> > }
> >
> > +
> > /* sleep button event */
> >
> > if ((status_register & ACPI_STATUS_SLEEP_BUTTON) &&
> > (enable_register & ACPI_ENABLE_SLEEP_BUTTON))
> > {
> > + printk("acpi: Sleep button pressed!\n");
> > int_status |= acpi_ev_fixed_event_dispatch
> > (ACPI_EVENT_SLEEP_BUTTON);
> > }
> >
> >
> > --
> > I'm [email protected]. "In my country we have almost anarchy and I
> > don't care."
> > Panos Katsaloulis describing me w.r.t. patents at
> > [email protected]
> >
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
"Grover, Andrew" <[email protected]> writes:
> This is not correct, because we want the power button to be
> configurable. The user should be able to redefine the power
> button's action, perhaps to only sleep the system. We currently
> surface button events to acpid, which then can do the right thing,
> including a shutdown -h now (which I assume notifies init).
That's just fine and dandy, but
[...]
> > + printk ("acpi: Power button pressed!\n");
[...]
> > + printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was actually working ;-)
[...]
--
http://www.penguinpowered.com/~vii
John R Lenton <[email protected]> writes:
[...]
> Just today a friend saw my box shutdown via the powerbutton and
> wondered if he coudln't set his up to trigger a different event
> (actually two: he wanted his sister - the guilty party - zapped, and
> a webcam shot of her face to prove it)...
That is in fact possible (given that you have the zapper) on certain
hardware with my pmpolicy patch
http://john.snoop.dk/programs/linux/offbutton
It uses APM instead of ACPI because ACPI doesn't work on my
computer. I have an updated version of the patch for 2.4.2, but I
haven't got round to uploading it.
--
http://www.penguinpowered.com/~vii
Pavel Machek <[email protected]> writes:
> Hi!
>
> > This is not correct, because we want the power button to be
> > configurable. The user should be able to redefine the power
> > button's action, perhaps to only sleep the system. We currently
> > surface button events to acpid, which then can do the right thing,
> > including a shutdown -h now (which I assume notifies init).
>
> There's no problem with configurability -- you can configure init as
> well. I saw it pretty much analogic to situation with Ctrl-Alt-Del:
> it also sends signal to init. Init then decides what to do. [I
> believe requiring acpid for such easy stuff is not neccessary...]
Using a signal to hit init with is a bit dubious because most signals
are hooked up for something else already. For example, SIGTERM sent to
my init (http://john.snoop.dk/programs/linux/jinit) would shutdown and
start sulogin, which is probably not what you want when you press the
off button. The FreeBSD init is similar FWIW (goes to single user
mode).
Some PM interfaces (e.g. APM) require a descision to be made by
software on such an event (to turn off or to "reject"). IMHO the best
way to do this is to exec a small script from kernelspace to get the
user's preferred policy; this is lighter weight than a daemon, doesn't
require some nasty magic number interface, and can be easily
programmed by any admin knowing sh or perl or whatever.
[...]
--
http://www.penguinpowered.com/~vii
I'm hesitant to do this, since 1) You can put those printk's in yourself to
find out if your particular system is working and 2) You can just cat
/proc/sys/event, hit a button, and you should see output if it works.
Regards -- Andy
> From: John Fremlin [mailto:[email protected]]
> "Grover, Andrew" <[email protected]> writes:
>
> > This is not correct, because we want the power button to be
> > configurable. The user should be able to redefine the power
> > button's action, perhaps to only sleep the system. We currently
> > surface button events to acpid, which then can do the right thing,
> > including a shutdown -h now (which I assume notifies init).
>
> That's just fine and dandy, but
>
> [...]
>
> > > + printk ("acpi: Power button pressed!\n");
>
> [...]
>
> > > + printk("acpi: Sleep button pressed!\n");
>
> Do you think you could keep the above part of the patch? It would be
> nice to know how much of ACPI was actually working ;-)
"Grover, Andrew" <[email protected]> writes:
[...]
> > > > + printk ("acpi: Power button pressed!\n");
> >
> > [...]
> >
> > > > + printk("acpi: Sleep button pressed!\n");
> >
> > Do you think you could keep the above part of the patch? It would be
> > nice to know how much of ACPI was actually working ;-)
> I'm hesitant to do this, since 1) You can put those printk's in
> yourself to find out if your particular system is working and 2) You
> can just cat /proc/sys/event, hit a button, and you should see
> output if it works.
Hmm. Pavel Machek could hardly be described as a newbie at hacking
stuff, and yet he says, "I hunted bug for few hours, thinking that
kernel does not get the event at all."
The printks are certainly clearer than cat'ing some binary garbage to
the console and will help out the casual user who doesn't want to
recompile kernel and reboot just to discover that the damn thing
doesn't work.
[...]
--
http://www.penguinpowered.com/~vii
Pavel Machek ([email protected]) wrote :
> Hi!
>
> Init should get to know that user pressed power button (so it can do
> shutdown and poweroff). Plus, it is nice to let user know that we can
> read such event. [I hunted bug for few hours, thinking that kernel
> does not get the event at all].
>
> Here's patch to do that. Please apply,
> Pavel
Isn't it better to just send the event to userspace , where
is it caught by apmd ( or whatever has replaced it ).
Then it can decide what to do about it, instead of dictating
a shutdown from kernel ( policy alert ;-) )
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
Hi!
> > Init should get to know that user pressed power button (so it can do
> > shutdown and poweroff). Plus, it is nice to let user know that we can
> > read such event. [I hunted bug for few hours, thinking that kernel
> > does not get the event at all].
> >
> > Here's patch to do that. Please apply,
> > Pavel
>
> Isn't it better to just send the event to userspace , where
> is it caught by apmd ( or whatever has replaced it ).
> Then it can decide what to do about it, instead of dictating
> a shutdown from kernel ( policy alert ;-) )
I'm not dictating policy: init is free to do anything it is configured
to, including /sbin/apmd --button_came or echo "Don't you dare to
plpress that button again".
>
>
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
Hi!
> > >Init should get to know that user pressed power button (so it can do
> > >shutdown and poweroff). Plus, it is nice to let user know that we can
> >
> > Not so hasty ;)
> >
> > >+ printk ("acpi: Power button pressed!\n");
> > >+ kill_proc (1, SIGTERM, 1);
>
> [reasons deleted]
>
> Is using a signal the appropriate thing to do anyway?
>
> Wouldn't there be better solutions?
>
> Perhaps a mechanism a user space program can use to communicate to the kernel
> (ala arpd/kerneld message queues, or something like klogd). Then a more
> general user space tool could be used that would do policy appropriate
> stuff, ending with init 0.
init _is_ the tool which is right for defining policy on such issues.
Take a look how UPS managment is handled.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> In article <[email protected]>,
> Miquel van Smoorenburg <[email protected]> wrote:
> >SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
> >good reason; on some (many?) systems, the shutdown scripts
> >include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> >"all processes except me". That means init will get hit with
> >SIGTERM occasionally during shutdown, and that might cause
> >weird things to happen.
> >
> >Perhaps SIGUSR1 ?
>
> In the immortal words of Max Headroom, t-t-talking to myself ;)
>
> In fact, the kernel should probably use a real-time signal
> with si_code set to 1 for ctrl-alt-del, 2 for the powerbutton etc.
>
> It should first check if process 1 (init) installed a handler
> for that real-time signal. If not, it should use the old
> signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest).
This is ugly as night, but SIGUSR1 looks okay.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Fri, 13 Apr 2001, Pavel Machek wrote:
> > Then a more general user space tool could be used that would do policy
> > appropriate stuff, ending with init 0.
> init _is_ the tool which is right for defining policy on such issues.
> Take a look how UPS managment is handled.
A power failure is a different thing from a power button press. There are
users (me for example) who want to have something different then "init 0"
mapped to the power button, for example a sleep state (since my box
doesn't have a dedicated sleep button). I doubt there are many people who
want something else than a shutdown if the power is out (although I think
there will be with suspend-to-disk working, so we might have to change UPS
handling here).
My plan for power management was to have a special daemon that would
decide what to do based on system state (battery status, local time, ...)
and events (power/sleep button, last user logged out, ...) [I know that
from a programmer's POV, both are events]. This daemon could, for example,
make sure that no services are affected, for example by priming WOL and
entering a not-so-deep sleep state instead of doing a suspend-to-disk if
someone is still listening on a port after the "shutdown unimportant
services" scripts have been run.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Hi,
On Mon, Apr 16, 2001 at 02:42:03PM +0200, Simon Richter wrote:
>
> A power failure is a different thing from a power button press. There are
> users (me for example) who want to have something different then "init 0"
> mapped to the power button, for example a sleep state (since my box
> doesn't have a dedicated sleep button). I doubt there are many people who
> want something else than a shutdown if the power is out (although I think
> there will be with suspend-to-disk working, so we might have to change UPS
> handling here).
And why not do exactly this with init? Have a look in /etc/inittab:
% grep power /etc/inittab
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
You can shut down your machine there, but you can also have it play a
cancan on power failure. It is up to your gusto. And now tell me, why
not choose a similar approach, but instead reinvent the wheel and
create a completely new mechanism?
Andreas
--
Besides, I think Slackware sounds better than 'Microsoft,' don't you?
-- Patrick Volkerding
On Mon, 16 Apr 2001, Andreas Ferber wrote:
> > A power failure is a different thing from a power button press.
> And why not do exactly this with init? Have a look in /etc/inittab:
> You can shut down your machine there, but you can also have it play a
> cancan on power failure. It is up to your gusto. And now tell me, why
> not choose a similar approach, but instead reinvent the wheel and
> create a completely new mechanism?
Because we'd be running out of signals soon, when all the other ACPI
events get available.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Hi!
> > > A power failure is a different thing from a power button press.
>
> > And why not do exactly this with init? Have a look in /etc/inittab:
>
> > You can shut down your machine there, but you can also have it play a
> > cancan on power failure. It is up to your gusto. And now tell me, why
> > not choose a similar approach, but instead reinvent the wheel and
> > create a completely new mechanism?
>
> Because we'd be running out of signals soon, when all the other ACPI
> events get available.
There are 32 signals, and signals can carry more information, if
required. I really think doing it way UPS-es are done is right
approach.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Mon, 16 Apr 2001, Pavel Machek wrote:
> > Because we'd be running out of signals soon, when all the other ACPI
> > events get available.
> There are 32 signals, and signals can carry more information, if
> required. I really think doing it way UPS-es are done is right
> approach.
Okay, but at least take a better signal than SIGINT, probably one that the
init maintainers like so it gets adopted faster (or extend SIGPWR).
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Simon Richter wrote:
>On Fri, 13 Apr 2001, Pavel Machek wrote:
>
>>>Then a more general user space tool could be used that would do policy
>>>appropriate stuff, ending with init 0.
>>>
>>init _is_ the tool which is right for defining policy on such issues.
>>
>>Take a look how UPS managment is handled.
>>
>
>A power failure is a different thing from a power button press. There are
>users (me for example) who want to have something different then "init 0"
>mapped to the power button, for example a sleep state (since my box
>doesn't have a dedicated sleep button). I doubt there are many people who
>want something else than a shutdown if the power is out (although I think
>there will be with suspend-to-disk working, so we might have to change UPS
>handling here).
>
>My plan for power management was to have a special daemon that would
>decide what to do based on system state (battery status, local time, ...)
>and events (power/sleep button, last user logged out, ...) [I know that
>from a programmer's POV, both are events]. This daemon could, for example,
>make sure that no services are affected, for example by priming WOL and
>entering a not-so-deep sleep state instead of doing a suspend-to-disk if
>someone is still listening on a port after the "shutdown unimportant
>services" scripts have been run.
>
> Simon
>
(root@qwerty)-(02:32pm Mon Apr 16)-(root)
# cat /etc/inittab | grep -1 CTRL
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
I believe that what is being referred to is similar. In which case, you
can put whatever the bleep you want here and do anything from popup a
message saying, "Shutdown denied" to immediately poweroff.
-b
--
Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!
Hi,
On Mon, Apr 16, 2001 at 11:44:20PM +0200, Simon Richter wrote:
>
> Okay, but at least take a better signal than SIGINT, probably one that the
> init maintainers like so it gets adopted faster (or extend SIGPWR).
Extending SIGPWR will break inits not yet supporting the extensions,
so this is IMO not an option. There should be used some other signal
which is simply ignored by an old init.
If we are actually introducing this new signal, maybe we should in
turn also provide for a generic init signalling API which could
be used later by other subsystems also? The distribution of such
events to other userspace processes (if there are some that want to
receive a subset of the events) can be perfectly done by init, so we
should IMO keep this stuff out of the kernel (I don't think that the
processing of such events will ever be performance critical).
Andreas
--
Of course you can't flap your arms and fly to the moon. After a while you'd
run out of air to push against.
> From: Pavel Machek [mailto:[email protected]]
> There are 32 signals, and signals can carry more information, if
> required. I really think doing it way UPS-es are done is right
> approach.
I would think that it would make sense to keep shutdown with all the other
power management events. Perhaps it will makes more sense to handle UPS's
through the power management code.
Regards -- Andy
On Tue, 17 Apr 2001, Andreas Ferber wrote:
> > Okay, but at least take a better signal than SIGINT, probably one that the
> > init maintainers like so it gets adopted faster (or extend SIGPWR).
> Extending SIGPWR will break inits not yet supporting the extensions,
> so this is IMO not an option. There should be used some other signal
> which is simply ignored by an old init.
Make it a config option then; the short description says "read help", the
long help says "you need init version x.y". People compiling their own
kernels should know what they're doing, and distributors usually know what
init they are packaging.
> The distribution of such events to other userspace processes (if there
> are some that want to receive a subset of the events) can be perfectly
> done by init, so we should IMO keep this stuff out of the kernel (I
> don't think that the processing of such events will ever be
> performance critical).
Fine with me as long as I get a decent interface where the policy manager
can plug into. :-)
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
"Grover, Andrew" <[email protected]> writes:
> > From: Pavel Machek [mailto:[email protected]]
> > There are 32 signals, and signals can carry more information, if
> > required. I really think doing it way UPS-es are done is right
> > approach.
> I would think that it would make sense to keep shutdown with all the
> other power management events. Perhaps it will makes more sense to
> handle UPS's through the power management code.
I'm happy add UPS functionality to the pmpolicy patch, if someone were
willing to test it - as I have no UPS ;-)
[...]
--
http://www.penguinpowered.com/~vii
On Mon, 16 Apr 2001, Grover, Andrew wrote:
> > From: Pavel Machek [mailto:[email protected]]
> > There are 32 signals, and signals can carry more information, if
> > required. I really think doing it way UPS-es are done is right
> > approach.
> I would think that it would make sense to keep shutdown with all the other
> power management events. Perhaps it will makes more sense to handle UPS's
> through the power management code.
I've already started to like the idea, since init is the tool that runs
all the time, not any ACPI or PM daemon, and it seems good to me that the
kernel always knows what to do on an event (signal init and think that it
has been dealt with).
init should provide a "direct" interface that doesn't rely on scripts
being present in certain directories (one less thing that can be broken)
for programs that want to receive these events. From the application
programmer's view this doesn't even make a difference if you have a shlib.
Maybe we should copy the init people? :-)
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
On Tue, Apr 17, 2001 at 08:16:00AM +0200, Simon Richter wrote:
>
> > Extending SIGPWR will break inits not yet supporting the extensions,
> > so this is IMO not an option. There should be used some other signal
> > which is simply ignored by an old init.
> Make it a config option then; the short description says "read help", the
> long help says "you need init version x.y". People compiling their own
> kernels should know what they're doing, and distributors usually know what
> init they are packaging.
The problem with this is that there is no single init. Most
distribution run the same SysV init, but there are quite a few init
replacements around. Should we really break all of them? We can simply
use another signal and build a generic (and extensible) signalling
mechanism around it, so I don't really see a reason why we should
break old inits.
Andreas
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Hi!
> > There are 32 signals, and signals can carry more information, if
> > required. I really think doing it way UPS-es are done is right
> > approach.
>
> I would think that it would make sense to keep shutdown with all the other
> power management events. Perhaps it will makes more sense to handle UPS's
> through the power management code.
Yes, that would be another acceptable solution. Situation where half
of power managment (UPS) is done with init and half with acpid is not
acceptable. [I doubt UPS users will want to switch. Why invent new
daemon when init is doing perfect job?]
However, I believe that simple way of sending signal to init is best
solution. It will suffice in 99% cases, users already know how to
configure init, and it does not need another process in userspace. In
remaining 1% case, init can simply notify acpid that even came.
I believe that one-patch is still worth applying. *Maybe* signal
should be changed to SIGUSR1 (to make room for SIGUSR2 to be sleep
button).
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Tue, 17 Apr 2001, Andreas Ferber wrote:
[Extending the current signalling mechanism]
> The problem with this is that there is no single init. Most
> distribution run the same SysV init, but there are quite a few init
> replacements around. Should we really break all of them?
We don't break anything as long as noone sets the config option. People
who want to use this feature need a current init.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
> From: Pavel Machek [mailto:[email protected]]
> > I would think that it would make sense to keep shutdown
> with all the other
> > power management events. Perhaps it will makes more sense
> to handle UPS's
> > through the power management code.
>
> Yes, that would be another acceptable solution. Situation where half
> of power managment (UPS) is done with init and half with acpid is not
> acceptable. [I doubt UPS users will want to switch. Why invent new
> daemon when init is doing perfect job?]
Hi Pavel,
I think init is doing a perfect job WRT UPSs because this is a trivial
application of power management. init wasn't really meant for this.
According to its man page:
"init...it's primary role is to create processes from a script in the file
/etc/inittab...It also controls autonomous processes required by any
particular system"
We are going to need some software that handles button events, as well as
thermal events, battery events, polling the battery, AC adapter status
changes, sleeping the system, and more.
We need WAY more flexibility than init provides. I find the argument that
init is already handling one minor power-related thing an unconvincing
reason why we should cram all power management through it.
Unix philosophy: "do one thing and do it well".
Regards -- Andy
Hi, Andy!
> > > I would think that it would make sense to keep shutdown
> > with all the other
> > > power management events. Perhaps it will makes more sense
> > to handle UPS's
> > > through the power management code.
> >
> > Yes, that would be another acceptable solution. Situation where half
> > of power managment (UPS) is done with init and half with acpid is not
> > acceptable. [I doubt UPS users will want to switch. Why invent new
> > daemon when init is doing perfect job?]
>
> I think init is doing a perfect job WRT UPSs because this is a trivial
> application of power management. init wasn't really meant for this.
> According to its man page:
>
> "init...it's primary role is to create processes from a script in the file
> /etc/inittab...It also controls autonomous processes required by any
> particular system"
>
> We are going to need some software that handles button events, as well as
> thermal events, battery events, polling the battery, AC adapter status
> changes, sleeping the system, and more.
I do not want to put battery/thermal/AC adapter status through
init. On *many* machines, button is only usefull device from ACPI (for
example all desktop machines). On desktop machine, you probably will
not want to configure/run acpid. Init should be able to do its job.
I agree that for notebooks where you want to handle thermal events
etc., acpid will be neccessary. I just do not want desktop people to
be forced to run acpid.
> We need WAY more flexibility than init provides. I find the argument that
> init is already handling one minor power-related thing an unconvincing
> reason why we should cram all power management through it.
It is doing UPS and c-a-d handling, which is *very* similar to what
you want to do on power button press 99% of time.
Pavel
PS: About thermal events -- do I need to do something special in order
for temperature to be measured?
I can send _TMP, and get temperature reading, but it does not change
with time -- I get the same value from boot on.
BTW here are hacks I use for easy control of ACPI. That way, I can
just for A in device_*; do echo -n '_TMP' > $A; done and get
temperature reading in syslog ;-).
Do you think some way to reflect acpi structure in proc would be good
idea?
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/common/cmeval.c linux/drivers/acpi/common/cmeval.c
--- clean/drivers/acpi/common/cmeval.c Wed Jan 31 16:14:27 2001
+++ linux/drivers/acpi/common/cmeval.c Fri Apr 6 08:45:21 2001
@@ -262,9 +262,10 @@
***************************************************************************/
ACPI_STATUS
-acpi_cm_execute_STA (
+acpi_cm_execute_rint (
ACPI_NAMESPACE_NODE *device_node,
- u32 *flags)
+ u32 *flags,
+ char *name)
{
ACPI_OPERAND_OBJECT *obj_desc;
ACPI_STATUS status;
@@ -273,14 +274,12 @@
/* Execute the method */
status = acpi_ns_evaluate_relative (device_node,
- METHOD_NAME__STA, NULL, &obj_desc);
- if (AE_NOT_FOUND == status) {
- *flags = 0x0F;
- status = AE_OK;
- }
-
+ name, NULL, &obj_desc);
+ if (ACPI_FAILURE (status))
+ return (status);
- else /* success */ {
+ /* I guess it used to be subtle bug here, on AE_NOT_FOUND, it did cm_remove_reference, anyway */
+ {
/* Did we get a return object? */
if (!obj_desc) {
@@ -306,3 +305,71 @@
return (status);
}
+
+
+ACPI_STATUS
+acpi_cm_execute_STA (
+ ACPI_NAMESPACE_NODE *device_node,
+ u32 *flags)
+{
+ ACPI_STATUS status;
+
+ status = acpi_cm_execute_rint(device_node, flags, "_STA");
+ if (status == AE_NOT_FOUND) {
+ *flags = 0x0F;
+ return AE_OK;
+ }
+ return status;
+}
+
+
+ACPI_STATUS
+acpi_cm_execute_any (
+ ACPI_NAMESPACE_NODE *device_node,
+ char *res,
+ char *name)
+{
+ ACPI_OPERAND_OBJECT *obj_desc;
+ ACPI_STATUS status;
+
+
+ /* Execute the method */
+
+ status = acpi_ns_evaluate_relative (device_node,
+ name, NULL, &obj_desc);
+ sprintf(res, "error");
+ if (ACPI_FAILURE (status))
+ return (status);
+
+ /* I guess it used to be subtle bug here, on AE_NOT_FOUND, it did cm_remove_reference, anyway */
+ {
+ /* Did we get a return object? */
+
+ if (!obj_desc) {
+ sprintf(res, "no return");
+ return (AE_OK);
+ }
+
+ /* Is the return object of the correct type? */
+
+ switch (obj_desc->common.type) {
+ case ACPI_TYPE_INTEGER:
+ sprintf(res, "int: %d", obj_desc->integer.value);
+ break;
+ case ACPI_TYPE_STRING:
+ sprintf(res, "string: %20s", obj_desc->string.pointer);
+ break;
+ deafult:
+ sprintf(res, "unknown", obj_desc->string.pointer);
+ break;
+ }
+
+ /* On exit, we must delete the return object */
+
+ acpi_cm_remove_reference (obj_desc);
+ }
+
+ return (status);
+}
+
+
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/events/evevent.c linux/drivers/acpi/events/evevent.c
--- clean/drivers/acpi/events/evevent.c Sun Apr 1 00:22:57 2001
+++ linux/drivers/acpi/events/evevent.c Wed Apr 4 01:08:11 2001
@@ -30,6 +30,8 @@
#include "acnamesp.h"
#include "accommon.h"
+#include <linux/signal.h>
+
#define _COMPONENT EVENT_HANDLING
MODULE_NAME ("evevent")
@@ -49,25 +51,15 @@
*************************************************************************/
ACPI_STATUS
-acpi_ev_initialize (
- void)
+acpi_ev_initialize (void)
{
ACPI_STATUS status;
-
- /* Make sure we have ACPI tables */
-
- if (!acpi_gbl_DSDT) {
+ if (!acpi_gbl_DSDT) /* Make sure we have ACPI tables */
return (AE_NO_ACPI_TABLES);
- }
-
-
- /* Make sure the BIOS supports ACPI mode */
- if (SYS_MODE_LEGACY == acpi_hw_get_mode_capabilities()) {
+ if (SYS_MODE_LEGACY == acpi_hw_get_mode_capabilities()) /* Make sure the BIOS supports ACPI mode */
return (AE_ERROR);
- }
-
acpi_gbl_original_mode = acpi_hw_get_mode();
@@ -77,38 +69,18 @@
* before handers are installed.
*/
- status = acpi_ev_fixed_event_initialize ();
- if (ACPI_FAILURE (status)) {
+ if (ACPI_FAILURE (status = acpi_ev_fixed_event_initialize ()))
return (status);
- }
-
- status = acpi_ev_gpe_initialize ();
- if (ACPI_FAILURE (status)) {
+ if (ACPI_FAILURE (status = acpi_ev_gpe_initialize ()))
return (status);
- }
-
- /* Install the SCI handler */
-
- status = acpi_ev_install_sci_handler ();
- if (ACPI_FAILURE (status)) {
+ if (ACPI_FAILURE (status = acpi_ev_install_sci_handler ()))
return (status);
- }
-
-
/* Install handlers for control method GPE handlers (_Lxx, _Exx) */
-
- status = acpi_ev_init_gpe_control_methods ();
- if (ACPI_FAILURE (status)) {
+ if (ACPI_FAILURE (status = acpi_ev_init_gpe_control_methods ()))
return (status);
- }
-
/* Install the handler for the Global Lock */
-
- status = acpi_ev_init_global_lock_handler ();
- if (ACPI_FAILURE (status)) {
+ if (ACPI_FAILURE (status = acpi_ev_init_global_lock_handler ()))
return (status);
- }
-
return (status);
}
@@ -131,6 +103,7 @@
{
int i = 0;
+ printk("acpi: Initializing fixed events\n");
/* Initialize the structure that keeps track of fixed event handlers */
for (i = 0; i < NUM_FIXED_EVENTS; i++) {
@@ -181,6 +154,7 @@
if ((status_register & ACPI_STATUS_PMTIMER) &&
(enable_register & ACPI_ENABLE_PMTIMER))
{
+ printk ("acpi: PM timer!\n");
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_PMTIMER);
}
@@ -189,22 +163,27 @@
if ((status_register & ACPI_STATUS_GLOBAL) &&
(enable_register & ACPI_ENABLE_GLOBAL))
{
+ printk ("acpi: BIOS wants to play!\n");
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_GLOBAL);
}
/* power button event */
if ((status_register & ACPI_STATUS_POWER_BUTTON) &&
- (enable_register & ACPI_ENABLE_POWER_BUTTON))
+ (enable_register & ACPI_ENABLE_POWER_BUTTON))
{
+ printk ("acpi: Power button pressed!\n");
+ kill_proc (1, SIGTERM, 1);
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_POWER_BUTTON);
}
+
/* sleep button event */
if ((status_register & ACPI_STATUS_SLEEP_BUTTON) &&
(enable_register & ACPI_ENABLE_SLEEP_BUTTON))
{
+ printk("acpi: Sleep button pressed!\n");
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_SLEEP_BUTTON);
}
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
--- clean/drivers/acpi/hardware/hwsleep.c Sun Apr 1 00:22:57 2001
+++ linux/drivers/acpi/hardware/hwsleep.c Wed Apr 4 00:11:19 2001
@@ -27,6 +27,7 @@
#include "acpi.h"
#include "acnamesp.h"
#include "achware.h"
+#include <linux/delay.h>
#define _COMPONENT HARDWARE
MODULE_NAME ("hwsleep")
@@ -50,7 +51,6 @@
ACPI_PHYSICAL_ADDRESS physical_address)
{
-
/* Make sure that we have an FACS */
if (!acpi_gbl_FACS) {
@@ -59,6 +59,8 @@
/* Set the vector */
+ printk("Setting waking_vector to %lx\n", physical_address);
+
if (acpi_gbl_FACS->vector_width == 32) {
* (u32 *) acpi_gbl_FACS->firmware_waking_vector = (u32) physical_address;
}
@@ -112,6 +114,12 @@
return (AE_OK);
}
+void
+while1(void)
+{
+ while(1);
+}
+
/******************************************************************************
*
* FUNCTION: Acpi_enter_sleep_state
@@ -136,6 +144,13 @@
u16 PM1_acontrol;
u16 PM1_bcontrol;
+/*
+ acpi_set_firmware_waking_vector(0xffff0);
+*/
+ acpi_set_firmware_waking_vector(&while1 - 0xc0000000);
+
+ printk("Entering power state %d\n", sleep_state);
+
/*
* _PSW methods could be run here to enable wake-on keyboard, LAN, etc.
*/
@@ -175,14 +190,23 @@
PM1_acontrol |= (type_a << acpi_hw_get_bit_shift (SLP_TYPE_X_MASK));
PM1_bcontrol |= (type_b << acpi_hw_get_bit_shift (SLP_TYPE_X_MASK));
- disable();
+ /*disable();*/
+ printk("hwsleep: Writing registers\n");
acpi_hw_register_write(ACPI_MTX_LOCK, PM1_a_CONTROL, PM1_acontrol);
acpi_hw_register_write(ACPI_MTX_LOCK, PM1_b_CONTROL, PM1_bcontrol);
+ printk("hwsleep: enabling sleep!\n");
acpi_hw_register_write(ACPI_MTX_LOCK, PM1_CONTROL,
(1 << acpi_hw_get_bit_shift (SLP_EN_MASK)));
+ printk("hwsleep: before enable\n");
- enable();
+ /*enable();*/
+ printk("hwsleep: after enable\n");
+ arg_list.count = 1;
+ arg_list.pointer = &arg;
+ acpi_evaluate_object(NULL, "\\_WAK", &arg_list, NULL);
+ printk("hwsleep: Waked up?\n");
+ mdelay(1000);
return (AE_OK);
}
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/namespace/nsxfobj.c linux/drivers/acpi/namespace/nsxfobj.c
--- clean/drivers/acpi/namespace/nsxfobj.c Sun Apr 1 00:23:00 2001
+++ linux/drivers/acpi/namespace/nsxfobj.c Tue Apr 10 00:19:01 2001
@@ -30,6 +30,10 @@
#include "acnamesp.h"
#include "acdispat.h"
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <asm/uaccess.h>
#define _COMPONENT NAMESPACE
MODULE_NAME ("nsxfobj")
@@ -592,7 +596,7 @@
status = acpi_cm_execute_STA (node, &flags);
if (ACPI_FAILURE (status)) {
- return (status);
+ return AE_OK;
}
if (!(flags & 0x01)) {
@@ -694,3 +698,203 @@
return (status);
}
+
+static int
+proc_read_device_info(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
+{
+ ACPI_HANDLE obj_handle = (u32) data;
+ ACPI_NAMESPACE_NODE *node;
+ ACPI_STATUS status;
+ char *p = page;
+ int len;
+ u32 flags;
+ DEVICE_ID device_id;
+
+ /* don't get info more than once for a single proc read */
+ if (off != 0)
+ goto end;
+
+ acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+
+ node = acpi_ns_convert_handle_to_entry (obj_handle);
+
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+ status = acpi_cm_execute_STA (node, &flags);
+ if (ACPI_FAILURE (status))
+ p += sprintf(p, "Present: No (%lx)\n", status);
+ else p += sprintf(p, "Present: Yes (flags %lx)\n", flags);
+
+ status = acpi_cm_execute_HID (node, &device_id);
+ if (!ACPI_FAILURE (status))
+ p += sprintf(p, "HID ident: %s\n", &device_id.buffer );
+
+ status = acpi_cm_execute_UID (node, &device_id);
+ if (!ACPI_FAILURE (status))
+ p += sprintf(p, "UID ident: %s\n", &device_id.buffer );
+
+ flags = 0xdeadbeef;
+ status = acpi_cm_execute_rint (node, &flags, "_PSC");
+ if (!ACPI_FAILURE (status))
+ p += sprintf(p, "Power status: %d\n", flags);
+
+ p += sprintf(p, "This is some random information\n");
+end:
+ len = (p - page);
+ if (len <= off+count) *eof = 1;
+ *start = page + off;
+ len -= off;
+ if (len>count) len = count;
+ if (len<0) len = 0;
+ return len;
+}
+
+int
+proc_write_device_info(struct file *file, const char *buffer,
+ unsigned long count, void *data)
+{
+ ACPI_HANDLE obj_handle = (u32) data;
+ ACPI_NAMESPACE_NODE *node;
+ ACPI_STATUS status;
+ int len;
+ u32 flags;
+ char buf[256], buf2[256];
+ DEVICE_ID device_id;
+
+ acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+
+ node = acpi_ns_convert_handle_to_entry (obj_handle);
+
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+ if (count > 250)
+ return -EPERM;
+ if (copy_from_user(buf, buffer, count))
+ return -EFAULT;
+ buf[count] = 0;
+ printk("acpi_write_device_info: %s...", buf);
+ flags = 0xdeadbeef;
+ status = acpi_cm_execute_any (node, buf2, buf);
+ if (ACPI_FAILURE (status))
+ printk("error: %lx (%s)\n", status, buf2);
+ else
+ printk("okay: %lx (%s)\n", status, buf2);
+
+ return -EL3RST;
+}
+
+
+static ACPI_STATUS
+acpi_ns_add_proc_callback (
+ ACPI_HANDLE obj_handle,
+ u32 nesting_level,
+ void *context,
+ void **return_value)
+{
+ ACPI_STATUS status;
+ ACPI_NAMESPACE_NODE *node;
+ u32 flags;
+ DEVICE_ID device_id;
+ ACPI_GET_DEVICES_INFO *info;
+
+
+ info = context;
+
+ acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+
+ printk("acpi_add_proc_callback: %lx\n", obj_handle);
+ node = acpi_ns_convert_handle_to_entry (obj_handle);
+
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+ if (!node) {
+ printk("No node?!\n");
+ return (AE_BAD_PARAMETER);
+ }
+
+ /*
+ * Run _STA to determine if device is present
+ */
+
+#if 0
+ status = acpi_cm_execute_STA (node, &flags);
+ if (ACPI_FAILURE (status)) {
+ return (AE_OK);
+ }
+
+ if (!(flags & 0x01)) {
+ /* don't return at the device or children of the device if not there */
+
+ return (AE_CTRL_DEPTH);
+ }
+#endif
+
+ {
+ char proc_name[120];
+ struct proc_dir_entry *proc;
+
+ status = acpi_cm_execute_HID (node, &device_id);
+
+ if ((status == AE_NOT_FOUND) || (ACPI_FAILURE (status)))
+ sprintf(proc_name, "power/device_unknown_%lx", obj_handle);
+ else sprintf(proc_name, "power/device_%s", device_id.buffer );
+ printk("ACPI: creating %s\n", proc_name);
+ proc = create_proc_read_entry(proc_name, 0, NULL,
+ proc_read_device_info, (void *) obj_handle);
+ if (!proc) printk(KERN_ERR "ACPI: Error creating %s\n", proc_name);
+ else {
+ proc->write_proc = proc_write_device_info;
+ }
+ }
+
+ return (AE_OK);
+}
+
+
+void
+acpi_namespace_init(
+ void)
+{
+ ACPI_STATUS status;
+ void ** return_value;
+
+ printk("ACPI: initializing namespace\n");
+
+ acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+ status = acpi_ns_walk_namespace (ACPI_TYPE_ANY,
+ ACPI_ROOT_OBJECT, ACPI_UINT32_MAX,
+ NS_WALK_UNLOCK,
+ acpi_ns_add_proc_callback, NULL,
+ return_value);
+
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+ return (status);
+}
+
+/*
+ _PSW -> lid does something interesting (unknown status).
+ _PSC -> PNP0303 (type error)
+ _LID -> lid does get lid status.
+ _ADR -> succeeds on many things
+ _CRS -> sometimes okay
+ _DIS -> 3 times okay
+ _EJ0 -> 1 time okay
+ _HID -> mostly returns integers
+ _PCL -> 2 times okay
+ _PRS -> 2 times okay
+ _PR[W0] -> 4 times okay
+ _PR1 -> okay once
+ _PSC -> 8 times okay
+ _PS3 -> 8 times okay, and seems to work
+ _PS2 -> okay once
+ _PS0 -> 8 times okay
+ _STA -> many times okay
+ _SRS -> error 3008
+ _UID -> many times okay.
+ _BST -> PNP0C0A battery status
+ _STM -> error 3008, sometimes (IDE set transfer timings)
+
+
+*/
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/power.c linux/drivers/acpi/power.c
--- clean/drivers/acpi/power.c Wed Jan 31 16:14:33 2001
+++ linux/drivers/acpi/power.c Thu Apr 5 00:51:28 2001
@@ -118,6 +118,7 @@
}
acpi_cmbatt_init();
+ acpi_namespace_init();
return 0;
}
diff -ur -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x *.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x *.flags -x *.bak clean/drivers/acpi/sys.c linux/drivers/acpi/sys.c
--- clean/drivers/acpi/sys.c Wed Jan 31 16:14:33 2001
+++ linux/drivers/acpi/sys.c Thu Apr 5 00:51:17 2001
@@ -79,11 +79,12 @@
/*
* Enter soft-off (S5)
*/
-static void
+void
acpi_power_off(void)
{
struct acpi_enter_sx_ctx ctx;
+ printk("Entering power off\n");
init_waitqueue_head(&ctx.wait);
ctx.state = ACPI_STATE_S5;
acpi_enter_sx_async(&ctx);
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
"Grover, Andrew" <[email protected]> writes:
> Hi Pavel,
>
> I think init is doing a perfect job WRT UPSs because this is a
> trivial application of power management. init wasn't really meant
> for this. According to its man page:
>
> "init...it's primary role is to create processes from a script in
> the file /etc/inittab...It also controls autonomous processes
> required by any particular system"
>
> We are going to need some software that handles button events, as
> well as thermal events, battery events, polling the battery, AC
> adapter status changes, sleeping the system, and more.
Dealing with events should be disjoint from polling the battery or
powerstatus. Many processes might reasonably simultaneously want to
provide a display to the user of the current power status.
However, button presses and so on should be handled by a single
process. Otherwise the kernel is unreasonably complicated by having to
deal with multiple processes' veto power, which could just as well and
more flexibly be handled in userspace.
I don't why there needs to be an additional daemon constantly running
to deal with button presses and power status changes. Apparently init
is already handling similar things: why should it not be extended to
include button presses?
Alternatively, why not forgo a daemon altogether? (This scheme is
already implemented in the pmpolicy patch, i.e. it is already
working.)
> We need WAY more flexibility than init provides.
Examples please.
[...]
--
http://www.penguinpowered.com/~vii
[do we want to move this to linux-power?]
> From: John Fremlin [mailto:[email protected]]
> > We are going to need some software that handles button events, as
> > well as thermal events, battery events, polling the battery, AC
> > adapter status changes, sleeping the system, and more.
>
> Dealing with events should be disjoint from polling the battery or
> powerstatus. Many processes might reasonably simultaneously want to
> provide a display to the user of the current power status.
There should be only one PM policy agent on the system. I don't care about
other processes that query for display purposes, but someone needs to be
alive and checking all the time in order to act on the user's wishes, and
shut down or sleep when the battery hits x minutes remaining, for example.
Let us call this "powerd", for sake of argument.
> However, button presses and so on should be handled by a single
> process. Otherwise the kernel is unreasonably complicated by having to
> deal with multiple processes' veto power, which could just as well and
> more flexibly be handled in userspace.
Exactly, only one entity can be in charge of setting the system's power
policy. So, let's not multiply entities needlessly -- let's make the button
policy manager also be powerd.
> I don't why there needs to be an additional daemon constantly running
> to deal with button presses and power status changes. Apparently init
> is already handling similar things: why should it not be extended to
> include button presses?
Unix philosophy: do one task and do it well. Now that power management is
big enough to be a task in itself (instead of just a minor feature) we
should break it out from unrelated functionality.
> Alternatively, why not forgo a daemon altogether? (This scheme is
> already implemented in the pmpolicy patch, i.e. it is already
> working.)
Because power policy needs to run continuously. Why? Because we need to poll
the battery for battery remaining, and we need to keep a moving average,
because the battery only provides instantaneous power consumption numbers.
Centralizing this means every UI applet can query it, and will show the same
battery remaining value.
Also, because thermal control is not 100% event driven - when we start
passive cooling on the CPU because of a thermal zone overheat, we have to
throttle, and then sample the temperature periodically until the temp goes
below the threshold. (ref: ACPI 2.0 spec chapter 12)
> > We need WAY more flexibility than init provides.
>
> Examples please.
See above. I know you may have an affinity for a call_usermodehelper-based
solution, but I hope I have been able to be clear on why I believe an actual
daemon is justified.
Regards -- Andy
PS apm already has apmd (which we would be replacing), so there will be no
net increase in system daemons.
> There should be only one PM policy agent on the system. I don't care about
> other processes that query for display purposes, but someone needs to be
The kernel pm code assumes there is a single agent issuing power management
requests via pm_* calls. User space is a different matter. There are numerous
good arguments for multiple policy agents, be they multiple applications or
multiple state machines in one system. Most power management seems to best
be modelled by multiple very simple algorithms running in parallel.
> solution, but I hope I have been able to be clear on why I believe an actual
> daemon is justified.
I would tend to agree here. If you want to wire it to init the fine but
pm is basically message passing kernel->user and possibly message reply to
allow veto/approve. APM provides a good API for this and there is a definite
incentive to make ACPI use the same messages, behaviour and extend it.
"Grover, Andrew" <[email protected]> writes:
> [do we want to move this to linux-power?]
I'm happy to as long as I'm cc'd.
[...]
IMHO the pm interface should be split up as following:
(1) Battery status, power status, UPS status polling. It
should be possible for lots of processes to do this
simultaneously. [That does not prohibit a single process
querying the kernel and all the others querying it.]
(2) Funky events happening to the physical machine, like a
button being pressed, the case being closed, etc. [Should this
include battery low warnings, power status changes? I don't
know.]
(3) Sending the machine to sleep, turning it off. It should be
possible to do this from userspace ;-)
Am I missing anything? Of course (1) and (2) could be combined into a
single daemon.
ATM the area is fraught with incompatibility. There are a ridiculous
number of power management systems - one per architecture almost. Each
has a different kernel-userspace interface. Every UPS has its own
interface too (?) ;-)
> There should be only one PM policy agent on the system.
Why?
As far as I see it, only some people need polling capabilities -
i.e. those on battery or UPS. Why should they be subjected to the
bloat etc. And those on battery might want multiple policies as Alan
pointed out.
[...]
--
http://www.penguinpowered.com/~vii
Alan Cox <[email protected]> writes:
[...]
> I would tend to agree here. If you want to wire it to init the fine
> but pm is basically message passing kernel->user and possibly
> message reply to allow veto/approve. APM provides a good API for
> this and there is a definite incentive to make ACPI use the same
> messages, behaviour and extend it.
I'm wondering if that veto business is really needed. Why not reject
*all* APM rejectable events, and then let the userspace event handler
send the system to sleep or turn it off? Anybody au fait with the APM
spec?
This would have the advantage that the veto stuff could be ripped out
and things made simpler.
--
http://www.penguinpowered.com/~vii
> I'm wondering if that veto business is really needed. Why not reject
> *all* APM rejectable events, and then let the userspace event handler
> send the system to sleep or turn it off? Anybody au fait with the APM
> spec?
Because apmd is optional
On Tue, 17 Apr 2001, Grover, Andrew wrote:
> We are going to need some software that handles button events, as well as
> thermal events, battery events, polling the battery, AC adapter status
> changes, sleeping the system, and more.
Yes, that will be a separate daemon that will also get the events. But I
think it's a good idea to have a simple interface that allows the user to
run arbitrary commands when ACPI events occur, even without acpid running
(think of singleuser mode, embedded systems, ...).
> Unix philosophy: "do one thing and do it well".
Another Unix philosophy: "keep it simple, stupid". :-)
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
> From: Simon Richter
> > We are going to need some software that handles button
> events, as well as
> > thermal events, battery events, polling the battery, AC
> adapter status
> > changes, sleeping the system, and more.
>
> Yes, that will be a separate daemon that will also get the
> events. But I
> think it's a good idea to have a simple interface that allows
> the user to
> run arbitrary commands when ACPI events occur, even without
> acpid running
> (think of singleuser mode, embedded systems, ...).
Fair enough. I don't think I would be out of line to say that our resources
are focused on enabling full ACPI functionality for Linux, including a
full-featured PM policy daemon. That said, I don't think there's anything
precluding the use of another daemon (or whatever) from using the ACPI
driver's interface.
> > Unix philosophy: "do one thing and do it well".
>
> Another Unix philosophy: "keep it simple, stupid". :-)
OK one more silly aphorism and I'll shut up. ;-) "Make it as simple as
possible, but no simpler."
Regards -- Andy
"Grover, Andrew" wrote:
>
> > From: Simon Richter
> > > We are going to need some software that handles button
> > events, as well as
> > > thermal events, battery events, polling the battery, AC
> > adapter status
> > > changes, sleeping the system, and more.
> >
> > Yes, that will be a separate daemon that will also get the
> > events. But I
> > think it's a good idea to have a simple interface that allows
> > the user to
> > run arbitrary commands when ACPI events occur, even without
> > acpid running
> > (think of singleuser mode, embedded systems, ...).
>
> Fair enough. I don't think I would be out of line to say that our resources
> are focused on enabling full ACPI functionality for Linux, including a
> full-featured PM policy daemon. That said, I don't think there's anything
> precluding the use of another daemon (or whatever) from using the ACPI
> driver's interface.
There's a ton of stuff to focus on :)
For example, if you focused on suspend and resume, I could start
implementing and testing that in the drivers :)
--
Jeff Garzik | "The universe is like a safe to which there is a
Building 1024 | combination -- but the combination is locked up
MandrakeSoft | in the safe." -- Peter DeVries
Alan Cox <[email protected]> writes:
> > I'm wondering if that veto business is really needed. Why not reject
> > *all* APM rejectable events, and then let the userspace event handler
> > send the system to sleep or turn it off? Anybody au fait with the APM
> > spec?
>
> Because apmd is optional
The veto stuff only comes into action, iff someone has registered as
willing to exercise this power. We would not break compatibility with
any std kernel by instead having a apmd send a "reject all" ioctl
instead, and so deal with events without having the pressure of having
to reject or accept them, and let us remove all the veto code from the
kernel driver. Or am I missing something?
--
http://www.penguinpowered.com/~vii
"Grover, Andrew" <[email protected]> writes:
[...]
> Fair enough. I don't think I would be out of line to say that our
> resources are focused on enabling full ACPI functionality for Linux,
> including a full-featured PM policy daemon. That said, I don't think
> there's anything precluding the use of another daemon (or whatever)
> from using the ACPI driver's interface.
ACPI != PM. I don't see why ACPI details should be exposed to PM
interface at all.
[...]
--
http://www.penguinpowered.com/~vii
Simon Richter <[email protected]> writes:
[...]
> Yes, that will be a separate daemon that will also get the
> events. But I think it's a good idea to have a simple interface that
> allows the user to run arbitrary commands when ACPI events occur,
> even without acpid running (think of singleuser mode, embedded
> systems, ...).
The pmpolicy patch presents such a simple interface. An executable
(the location of which is configurable) is run from the kernel with
certain arguments.
The advantages of this:
(1) No nasty magic number binary interface, everything is text ->
(2) Any sysadmin can easily write an event handler in sh, perl, or
whatever scripting language, i.e. the userspace handler is much
simpler.
(3) No events, no bloat.
(4) Kernel code is probably shorter (tho' less standard) than having a
special device or procfs node.
(5) Efficiency: the alternative is to have a program like APMD
decoding the nasty binary interface and then spawning a shell script
to deal with it.
I myself am starting to dislike the idea: it was mostly motivated by
the need to exercise a veto on APM events. This is in fact not
necessary, if I understand correctly. An interface allowing multiple
listeners is preferable.
It remains to contact all the maintainers of the various PM and UPS
systems to flesh out exactly what the interface should be capable of
;-)
[...]
--
http://www.penguinpowered.com/~vii
> willing to exercise this power. We would not break compatibility with
> any std kernel by instead having a apmd send a "reject all" ioctl
> instead, and so deal with events without having the pressure of having
> to reject or accept them, and let us remove all the veto code from the
> kernel driver. Or am I missing something?
That sounds workable. But the same program could reply to the events just
as well as issue the ioctl 8)
Alan Cox <[email protected]> writes:
> > willing to exercise this power. We would not break compatibility
> > with any std kernel by instead having a apmd send a "reject all"
> > ioctl instead, and so deal with events without having the pressure
> > of having to reject or accept them, and let us remove all the veto
> > code from the kernel driver. Or am I missing something?
>
> That sounds workable. But the same program could reply to the events
> just as well as issue the ioctl 8)
Having more than one program holding the veto on each event is a bit
of a hassle. Keeping track of "replies" is also a bit of a
hassle. It'd be simpler to let userspace handle everything in line
with e.g. the ACPI power button press, and suspend or turn off the
machine in the normal manner.
[...]
--
http://www.penguinpowered.com/~vii
On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote:
> > willing to exercise this power. We would not break compatibility with
> > any std kernel by instead having a apmd send a "reject all" ioctl
> > instead, and so deal with events without having the pressure of having
> > to reject or accept them, and let us remove all the veto code from the
> > kernel driver. Or am I missing something?
>
> That sounds workable. But the same program could reply to the events just
> as well as issue the ioctl 8)
AFAICT some APM BIOSes get impatient if you don't acknowledge/reject the
requests fast enough, and start to go bananas. By always rejecting requests
and then making user requests instead at some time later, we might eliminate
this problem (or just cause new ones).
Also, I don't think the "critical suspend" message can be rejected at all,
so it would have to be a special case where currently I don't think it's too
bad.
Have fun,
Avery
Avery Pennarun <[email protected]> writes:
> On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote:
>
> > > willing to exercise this power. We would not break compatibility with
> > > any std kernel by instead having a apmd send a "reject all" ioctl
> > > instead, and so deal with events without having the pressure of having
> > > to reject or accept them, and let us remove all the veto code from the
> > > kernel driver. Or am I missing something?
> >
> > That sounds workable. But the same program could reply to the events just
> > as well as issue the ioctl 8)
>
> AFAICT some APM BIOSes get impatient if you don't acknowledge/reject
> the requests fast enough, and start to go bananas. By always
> rejecting requests and then making user requests instead at some
> time later, we might eliminate this problem (or just cause new
> ones).
Indeed. Neither proposal has however received wide testing as far as I
know. The userspace ACCEPT/REJECT method was available as a patch from
Stephen for a while though.
> Also, I don't think the "critical suspend" message can be rejected
> at all, so it would have to be a special case where currently I
> don't think it's too bad.
ATM it is a "special case" - we print a message if we try to reject a
critical suspend. However the case is not so special that it requires
more than a line or two ;-)
I don't think there is any cause for concern on that front.
[...]
--
http://www.penguinpowered.com/~vii
> From: John Fremlin [mailto:[email protected]]
> [...]
>
> > Fair enough. I don't think I would be out of line to say that our
> > resources are focused on enabling full ACPI functionality for Linux,
> > including a full-featured PM policy daemon. That said, I don't think
> > there's anything precluding the use of another daemon (or whatever)
> > from using the ACPI driver's interface.
>
> ACPI != PM. I don't see why ACPI details should be exposed to PM
> interface at all.
ACPI has by far the richest set of capabilities. It is a superset of APM.
Therefore a combined APM/ACPI interface is going to look a lot like an ACPI
interface.
IMHO an abstracted interface at this point is overengineering. Maybe later
it will make sense, though.
Regards -- Andy
Grover, Andrew writes:
> IMHO an abstracted interface at this point is overengineering.
ACPI is the epitome of overengineering.
An abstracted interface would allow simpler systems to avoid all of
the bloated garbage ACPI brings with it. Sorry, Alan hit it right on
the head, ACPI is not much more than keeping speedstep proprietary.
Later,
David S. Miller
[email protected]
"Grover, Andrew" <[email protected]> writes:
[...]
> > ACPI != PM. I don't see why ACPI details should be exposed to PM
> > interface at all.
>
> ACPI has by far the richest set of capabilities. It is a superset of
> APM. Therefore a combined APM/ACPI interface is going to look a lot
> like an ACPI interface.
First, lets stop being so Intel/x86 centric ;-)
There are more PM interfaces than APM/ACPI as Stephen Rothwell pointed
out to me: more are already supported by the kernel. PPC has one, ARM
has one, etc. And that's not even touching on UPSs and miscellaneous
portable whatnots with their own special PM bits and pieces like IBM
laptops.
ACPI might be able to handle all that but it would require a very
complex interface, if what I've seen of ACPI is anything to go by. Is
this correct?
A much simpler interface might not lose much functionality.
> IMHO an abstracted interface at this point is overengineering. Maybe
> later it will make sense, though.
Each PM scheme has its own daemon and suspend/sleep tools at the
moment. It makes sense to have just one daemon and toolset so that
advanced functionality can be shared. Should the kernel present a
common interface like HID, or should the daemon be able to understand
all the various protocols (like gpm for mice)?
--
http://www.penguinpowered.com/~vii
"Grover, Andrew" wrote:
> ACPI has by far the richest set of capabilities. It is a superset of APM.
> Therefore a combined APM/ACPI interface is going to look a lot like an ACPI
> interface.
>
> IMHO an abstracted interface at this point is overengineering. Maybe later
> it will make sense, though.
IMHO We want to be able to support at least three cases: APM, ACPI, and
native PM.
--
Jeff Garzik | "The universe is like a safe to which there is a
Building 1024 | combination -- but the combination is locked up
MandrakeSoft | in the safe." -- Peter DeVries
John Fremlin <[email protected]> writes:
[...]
> IMHO the pm interface should be split up as following:
Nobody has disagreed: therefore this separation must be perfect ;-)
> (1) Battery status, power status, UPS status polling. It
> should be possible for lots of processes to do this
> simultaneously. [That does not prohibit a single process
> querying the kernel and all the others querying it.]
Solution. Have a bunch of procfs or dev nodes each giving info on a
particular power source, like now, but vaguely standardise the output.
> (2) Funky events happening to the physical machine, like a
> button being pressed, the case being closed, etc. [Should this
> include battery low warnings, power status changes? I don't
> know.]
Solution. Have a special procfs or dev node that any number of people
can select(2) or read(2). Protocol text. Syntax:
<event> <WS> <subsystem> <WS> <description> <LF>
Where <event> is one of the strings
OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, <WS> is a space character,
<subsystem> is a word signifying the kernel pm interface responsible
for generating th event, <description> is an arbitrary string. <LF> is
a newline character \n.
This is flexible and simple. It means a reasonable default behaviour
can be suggested by the kernel (OFF,SLEEP,etc.) for events that
userspace doesn't know about and yet userspace can choose fine grained
policy and provide helpful error messages based on the exact event by
checking the description.
[...]
> (3) Sending the machine to sleep, turning it off. It should be
> possible to do this from userspace ;-)
I would suggest that all pm capable objects should be able to be
controlled individually. E.g. you should be able to send your monitor
to sleep alone, leaving other stuff running. Fbdrivers are already
capable of this on some archs.
IOW I suggest a nice FS with a dir per PM capable device. In this
dir would be
name - descriptive text name of device class
wake - writing to this node wakes device
sleep - writing a number n (text encoded) sends the device to
sleep in such a way that it can be back in action in no less
than n seconds after a wakeup call on a vague guess
basis. Reading from it gets errno.
off - writing to this node puts device in deepest possible
sleep, possibly losing state. Reading gets errno.
Like the proc/sys/net/ipv4/neigh stuff you can have an all/ dir that'd
try to whatever to everything. Hotunplug can be handled.
Any objections? Would such a patch be accepted by the powers that be?
[...]
--
http://www.penguinpowered.com/~vii
> This is flexible and simple. It means a reasonable default behaviour
> can be suggested by the kernel (OFF,SLEEP,etc.) for events that
> userspace doesn't know about and yet userspace can choose fine grained
> policy and provide helpful error messages based on the exact event by
The entire PM layer for the embedded board I worked on was 3Kbytes. How small
will yours be 8)
> > IMHO the pm interface should be split up as following:
>
> Nobody has disagreed: therefore this separation must be perfect ;-)
I once heard that patience is a virtue. :)
> > (1) Battery status, power status, UPS status polling. It
> > should be possible for lots of processes to do this
> > simultaneously. [That does not prohibit a single process
> > querying the kernel and all the others querying it.]
>
> Solution. Have a bunch of procfs or dev nodes each giving info on a
> particular power source, like now, but vaguely standardise the output.
I concur. This is easy, and clean.
> > (2) Funky events happening to the physical machine, like a
> > button being pressed, the case being closed, etc. [Should this
> > include battery low warnings, power status changes? I don't
> > know.]
I can see at least two types of events - (forgive the lack of colorful
terminology) passive and active. Passive events are simply providing
status updates, much like the events described above. These are simply so
some UI can notify the user of things like a low battery or detection of
an AC adapter. These can be handled in much the same way as described
above.
Active events require some sort of action by user space, like a shutdown
request initiated by a button press or a dead battery. See the next
comment.
> Solution. Have a special procfs or dev node that any number of people
> can select(2) or read(2). Protocol text. Syntax:
>
> <event> <WS> <subsystem> <WS> <description> <LF>
>
> Where <event> is one of the strings
> OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, <WS> is a space character,
> <subsystem> is a word signifying the kernel pm interface responsible
> for generating th event, <description> is an arbitrary string. <LF> is
> a newline character \n.
>
> This is flexible and simple. It means a reasonable default behaviour
> can be suggested by the kernel (OFF,SLEEP,etc.) for events that
> userspace doesn't know about and yet userspace can choose fine grained
> policy and provide helpful error messages based on the exact event by
> checking the description.
First, Is there any reason why the kernel should do more text processing?
It is better left for user space. Besides, enumerated values translated by
userspace seems more efficient than copying and parsing strings.
Having a daemon that sits in user space and waits for system events
(denoted by enumerated values in some /proc or /dev file) seems simple
enough. When it gets the request to power down, it handles calling init
and whatever else it wants to do. When it gets notification that the
laptop was plugged into the base station, it can look for new devices and
load the modules for them.
This can also handle the user-dictated policy, which I haven't seen
discussed yet. For instance, when you close the lid or press the power
button, the system can enter suspend or it can power off. If the kernel
simply exported the event, the userspace daemon could simply check its
config file for the proper thing to do and initiate the transition.
> > (3) Sending the machine to sleep, turning it off. It should be
> > possible to do this from userspace ;-)
>
> I would suggest that all pm capable objects should be able to be
> controlled individually. E.g. you should be able to send your monitor
> to sleep alone, leaving other stuff running. Fbdrivers are already
> capable of this on some archs.
>
> IOW I suggest a nice FS with a dir per PM capable device. In this
> dir would be
>
> name - descriptive text name of device class
>
> wake - writing to this node wakes device
>
> sleep - writing a number n (text encoded) sends the device to
> sleep in such a way that it can be back in action in no less
> than n seconds after a wakeup call on a vague guess
> basis. Reading from it gets errno.
>
> off - writing to this node puts device in deepest possible
> sleep, possibly losing state. Reading gets errno.
Sure, but does it really make sense for anything but system sleep states?
ACPI defines a mechnanism for runtime power management, where devices will
go into sleep states if they're not being used. Given proper heuristics
for controlling this, user-initiated suspension of individual devices
doesn't seem necessary. And, given a proper abstraction in the PM layer,
this should be extendable, to some extent, to other low-level PM schemes.
-pat
[email protected] said:
> IMHO an abstracted interface at this point is overengineering. Maybe
> later it will make sense, though.
Absolutely not. It makes sense now. The abstracted interface is not required
just to combine the interface to APM and ACPI. What John said was
"ACPI != PM". Note that APM != PM either.
We have people who write _real_ code (esp. for embedded systems) to do power
management. None of this UDI-written-in-bytecode style stuff - real C code.
I.e. "the preferred form of the work for making modifications to it" :)
_That_ is the first-class citizen here, and _that_ is the thing for which we
require a generic power management API, allowing userspace to set and manage
the power management policies for individual devices, etc., as well as
managing the system-wide sleep macrostates.
It may happen that ACPI and the real native power management code can
happily share an interface. Where there's a conflict, though, the native
implementations should define the interface, and ACPI needs to try to fit
in.
--
dwmw2
Patrick Mochel <[email protected]> writes:
> > > IMHO the pm interface should be split up as following:
> >
> > Nobody has disagreed: therefore this separation must be perfect ;-)
>
> I once heard that patience is a virtue. :)
>
> > > (1) Battery status, power status, UPS status polling. It
> > > should be possible for lots of processes to do this
> > > simultaneously. [That does not prohibit a single process
> > > querying the kernel and all the others querying it.]
> >
> > Solution. Have a bunch of procfs or dev nodes each giving info on a
> > particular power source, like now, but vaguely standardise the output.
[...]
> I can see at least two types of events - (forgive the lack of colorful
> terminology) passive and active. Passive events are simply providing
> status updates, much like the events described above. These are simply so
> some UI can notify the user of things like a low battery or detection of
> an AC adapter. These can be handled in much the same way as described
> above.
No they can't. They only happen once. Battery status exists all the
time.
[...]
--
http://www.penguinpowered.com/~vii
Patrick Mochel <[email protected]> writes:
[...]
> > Solution. Have a special procfs or dev node that any number of people
> > can select(2) or read(2). Protocol text. Syntax:
> >
> > <event> <WS> <subsystem> <WS> <description> <LF>
> >
> > Where <event> is one of the strings
> > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, <WS> is a space character,
> > <subsystem> is a word signifying the kernel pm interface responsible
> > for generating th event, <description> is an arbitrary string. <LF> is
> > a newline character \n.
> >
> > This is flexible and simple. It means a reasonable default behaviour
> > can be suggested by the kernel (OFF,SLEEP,etc.) for events that
> > userspace doesn't know about and yet userspace can choose fine grained
> > policy and provide helpful error messages based on the exact event by
> > checking the description.
>
> First, Is there any reason why the kernel should do more text processing?
Kernel does no text processing. Kernel merely gives text instead of
magic numbers to the stream of bytes.
> It is better left for user space. Besides, enumerated values
> translated by userspace seems more efficient than copying and
> parsing strings.
Oh? Do you honestly believe there will be in any way a detectable
difference?
> Having a daemon that sits in user space and waits for system events
> (denoted by enumerated values in some /proc or /dev file) seems simple
> enough.
Yes, but text strings are simpler. You don't have to export magic
numbers in some kernel header (causing no end of woe). You can just
cat /proc/pm/events to the console and understand it, and just about
anybody with the rudiments of knowledge about programming in any
language can write an event handler - even without having to know
hardly anything about or look at the kernel source because the
interface is so transparent and simple.
> When it gets the request to power down, it handles calling init and
> whatever else it wants to do. When it gets notification that the
> laptop was plugged into the base station, it can look for new
> devices and load the modules for them.
Exactly. Right. Bang on target - but with text strings you can do it
in a line or two of perl, and the kernel side is not made any more
complex.
> This can also handle the user-dictated policy, which I haven't seen
> discussed yet. For instance, when you close the lid or press the power
> button, the system can enter suspend or it can power off. If the kernel
> simply exported the event, the userspace daemon could simply check its
> config file for the proper thing to do and initiate the transition.
Exactly what I was suggesting. In this case, you'd get the event
SLEEP ACPI Laptop case closed
and your perl script could do something vaguely like
/ACPI Laptop case closed$/ && system "shutdown -p now";
to turn the machine off instead of sleeping.
[...]
> > sleep - writing a number n (text encoded) sends the device to
> > sleep in such a way that it can be back in action in no less
> > than n seconds after a wakeup call on a vague guess
> > basis. Reading from it gets errno.
Probably microseconds would be a more useful unit.
> > off - writing to this node puts device in deepest possible
> > sleep, possibly losing state. Reading gets errno.
>
> Sure, but does it really make sense for anything but system sleep
> states? ACPI defines a mechnanism for runtime power management,
> where devices will go into sleep states if they're not being
> used. Given proper heuristics for controlling this, user-initiated
> suspension of individual devices doesn't seem necessary. And, given
> a proper abstraction in the PM layer, this should be extendable, to
> some extent, to other low-level PM schemes.
OK, so add another node, something like
boredafter - writing a number of milliseconds tells device to
go to some sort of sleep after that time has elapsed without
activity.
--
http://www.penguinpowered.com/~vii
> > > > (1) Battery status, power status, UPS status polling. It
> > > > should be possible for lots of processes to do this
> > > > simultaneously. [That does not prohibit a single process
> > > > querying the kernel and all the others querying it.]
> > >
> > > Solution. Have a bunch of procfs or dev nodes each giving info on a
> > > particular power source, like now, but vaguely standardise the output.
>
> [...]
>
> > I can see at least two types of events - (forgive the lack of colorful
> > terminology) passive and active. Passive events are simply providing
> > status updates, much like the events described above. These are simply so
> > some UI can notify the user of things like a low battery or detection of
> > an AC adapter. These can be handled in much the same way as described
> > above.
>
> No they can't. They only happen once. Battery status exists all the
> time.
Yes they can. My point was they can be handled from userspace in the same
way that battery status does - by doing a select on a file in /proc or
/dev. Once in a while (or constantly) they get data from the kernel -
battery status, AC change, etc - that can be then translated and displayed
in the UI.
-pat
Patrick Mochel <[email protected]> writes:
[...]
> > > I can see at least two types of events - (forgive the lack of colorful
> > > terminology) passive and active. Passive events are simply providing
> > > status updates, much like the events described above. These are simply so
> > > some UI can notify the user of things like a low battery or detection of
> > > an AC adapter. These can be handled in much the same way as described
> > > above.
> >
> > No they can't. They only happen once. Battery status exists all the
> > time.
>
> Yes they can. My point was they can be handled from userspace in the
> same way that battery status does - by doing a select on a file in
> /proc or /dev. Once in a while (or constantly) they get data from
> the kernel - battery status, AC change, etc - that can be then
> translated and displayed in the UI.
I think these events have a generic utility not specific to UIs. In
particular, when ones battery is running out, one would quite like the
event manager to be notified. As is currently the case with e.g. apmd.
Polling on battery charge left or battery voltage/current is different
from this, surely? Why should such programs have to be notified that
the battery was low? The event itself is pretty useless if you're
doing polling but there is no point throwing it away, in case you
aren't.
[...]
--
http://www.penguinpowered.com/~vii
Hi!
> > > I'm wondering if that veto business is really needed. Why not reject
> > > *all* APM rejectable events, and then let the userspace event handler
> > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > spec?
> >
> > Because apmd is optional
>
> The veto stuff only comes into action, iff someone has registered as
> willing to exercise this power. We would not break compatibility with
> any std kernel by instead having a apmd send a "reject all" ioctl
> instead, and so deal with events without having the pressure of having
> to reject or accept them, and let us remove all the veto code from the
> kernel driver. Or am I missing something?
No, this looks reasonable.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> [...]
>
> > I would tend to agree here. If you want to wire it to init the fine
> > but pm is basically message passing kernel->user and possibly
> > message reply to allow veto/approve. APM provides a good API for
> > this and there is a definite incentive to make ACPI use the same
> > messages, behaviour and extend it.
>
> I'm wondering if that veto business is really needed. Why not reject
> *all* APM rejectable events, and then let the userspace event handler
> send the system to sleep or turn it off? Anybody au fait with the APM
> spec?
My thinkpad actually started blinking with some LED when you pressed
the button. LED went off when you rejected or when sleep was
completed. So you would loose visual indication of "system is now
going to sleep". But I guess that is very little loose for the loose
of complexity.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> > This can also handle the user-dictated policy, which I haven't seen
> > discussed yet. For instance, when you close the lid or press the power
> > button, the system can enter suspend or it can power off. If the kernel
> > simply exported the event, the userspace daemon could simply check its
> > config file for the proper thing to do and initiate the transition.
>
> Exactly what I was suggesting. In this case, you'd get the event
>
> SLEEP ACPI Laptop case closed
>
> and your perl script could do something vaguely like
>
> /ACPI Laptop case closed$/ && system "shutdown -p now";
>
> to turn the machine off instead of sleeping.
Lid is polled device, at least in ACPI case. Take a look at current
/proc/power/ -- it contains file "ac" saying "on-line" or
"off-line". I believe we should add another device file "lid"
containing either "open" or "closed"
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek <[email protected]> writes:
[...]
> > I'm wondering if that veto business is really needed. Why not reject
> > *all* APM rejectable events, and then let the userspace event handler
> > send the system to sleep or turn it off? Anybody au fait with the APM
> > spec?
>
> My thinkpad actually started blinking with some LED when you pressed
> the button. LED went off when you rejected or when sleep was
> completed.
Does the led start blinking when the system sends an apm suspend? In
that case I don't think you'd notice the brief period between the
REJECT and the following suspend from userspace ;-)
[...]
--
http://www.penguinpowered.com/~vii
Hi!
> > > I'm wondering if that veto business is really needed. Why not reject
> > > *all* APM rejectable events, and then let the userspace event handler
> > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > spec?
> >
> > My thinkpad actually started blinking with some LED when you pressed
> > the button. LED went off when you rejected or when sleep was
> > completed.
>
> Does the led start blinking when the system sends an apm suspend? In
> that case I don't think you'd notice the brief period between the
> REJECT and the following suspend from userspace ;-)
Not so brief -- suspend to disk takes quite a lot of time. However, it
is probably not too important if user can see blinking led or not.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
John Fremlin wrote:
> > > I'm wondering if that veto business is really needed. Why not reject
> > > *all* APM rejectable events, and then let the userspace event handler
> > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > spec?
> >
> > My thinkpad actually started blinking with some LED when you pressed
> > the button. LED went off when you rejected or when sleep was
> > completed.
>
> Does the led start blinking when the system sends an apm suspend? In
> that case I don't think you'd notice the brief period between the
> REJECT and the following suspend from userspace ;-)
Are you sure? A suspend takes about 5-10 seconds on my laptop.
(It was noticably faster with 2.3 kernels, btw. Now it spends a second
or two apparently not noticing the APM event (though the BIOS is making
the speaker beep), then syncing the disk, then maybe another pause, then
maybe some more disk activity, then finally shutting down. 2.3 started
the disk activity immediately and didn't pause. Perhaps 2.4.3 mm
problems?)
-- Jamie
Jamie Lokier <[email protected]> writes:
[...]
> Are you sure? A suspend takes about 5-10 seconds on my laptop.
You mean when you tell the apm driver from userspace to suspend?
> (It was noticably faster with 2.3 kernels, btw. Now it spends a second
> or two apparently not noticing the APM event (though the BIOS is making
> the speaker beep), then syncing the disk,
The BIOS got the event, problem is in BIOS surely?
[...]
--
http://www.penguinpowered.com/~vii
Hi!
> > > > I'm wondering if that veto business is really needed. Why not reject
> > > > *all* APM rejectable events, and then let the userspace event handler
> > > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > > spec?
> > >
> > > My thinkpad actually started blinking with some LED when you pressed
> > > the button. LED went off when you rejected or when sleep was
> > > completed.
> >
> > Does the led start blinking when the system sends an apm suspend? In
> > that case I don't think you'd notice the brief period between the
> > REJECT and the following suspend from userspace ;-)
>
> Are you sure? A suspend takes about 5-10 seconds on my laptop.
Ouch? Really?
What I do is killall apmd, then apm -s and it is more or less
instant. [Are you using suspend-to-disk? AFAICS my toshiba can not do
suspend to disk, that's why I'm interested].
> (It was noticably faster with 2.3 kernels, btw. Now it spends a second
> or two apparently not noticing the APM event (though the BIOS is making
> the speaker beep ), then syncing the disk, then maybe another pause, then
> maybe some more disk activity, then finally shutting down. 2.3 started
> t he disk activity immediately and didn't pause. Perhaps 2.4.3 mm
> problems?)
Take a look what apmd does. I'm killing it before apm -s.
Pavel
> From: David S. Miller [mailto:[email protected]]
> > IMHO an abstracted interface at this point is overengineering.
>
> ACPI is the epitome of overengineering.
Hi David,
I definitely set myself up for that one. ;-) And, you're not wrong. But,
let's be clear on one thing, there are two interfaces under consideration:
1) How the kernel interacts with the platform to do power
management/configuration and 2) How the OS exposes its PM interface to ring
3.
#1 is defined by ACPI and it's too late to improve it - it's the standard. I
think it's a net improvement (by getting rid of several ugly existing
interfaces like APM, pnpbios, and MPS tables) but also realize that *we have
stepped up* to implement ACPI support, a not inconsiderable effort. You may
think this is cleaning up a mess we made ourselves but there are clear,
large, advantages that ACPI-enabled systems will have over non-ACPI ones.
Windows 2000 is a great mobile OS in large part due to ACPI.
#2 was what I was referring to with the overengineering comment. Basically,
we want to put PM policy in userspace because that's where Unix puts these
things, right? We have more functionality than other PM options, therefore
we need the most elaborate PM kernel<-->user interface. My point was that we
don't even have a functional PM policy daemon at this point, so it's a
little early to start generalizing the interface, in my opinion, but a
generalized PM interface is OK, as long as it exposes at least the level of
functionality ACPI does. A generalized interface is more work, and I see no
benefit *right now*. We'll see when someone designs one, I guess.
> An abstracted interface would allow simpler systems to avoid all of
> the bloated garbage ACPI brings with it. Sorry, Alan hit it right on
> the head, ACPI is not much more than keeping speedstep proprietary.
This is not correct. ACPI 1.0 existed before SpeedStep was even conceived
of. The 1.0 spec contains no mention of processor performance states, or
device performance states. ACPI 2.0 does, but it provides a generic
interface for the OS to control processor performance, thus commoditizing
SpeedStep-type functionality in the future.
Clear?
Regards -- Andy
Pavel Machek wrote:
> > Are you sure? A suspend takes about 5-10 seconds on my laptop.
>
> Ouch? Really?
No, I was thinking of one of the earlier 2.4 kernels. 2.4.3 seems
faster again.
> What I do is killall apmd, then apm -s and it is more or less
> instant. [Are you using suspend-to-disk? AFAICS my toshiba can not do
> suspend to disk, that's why I'm interested].
Mind doesn't do suspend-to-disk either. I think it can with Windows but
I've never run Windows on it to find out :-)
I've always presumed the disk activity that starts after closing the lid
and before powering down is due to the kernel, or maybe apmd, calling
sync().
> > (It was noticably faster with 2.3 kernels, btw. Now it spends a second
> > or two apparently not noticing the APM event (though the BIOS is making
> > the speaker beep ), then syncing the disk, then maybe another pause, then
> > maybe some more disk activity, then finally shutting down. 2.3 started
> > t he disk activity immediately and didn't pause. Perhaps 2.4.3 mm
> > problems?)
>
> Take a look what apmd does. I'm killing it before apm -s.
Hmm. Perhaps apmd needs a "do not sync" option, for when you don't care.
-- Jamie
Jamie Lokier writes:
> Hmm. Perhaps apmd needs a "do not sync" option, for when you don't care.
Alternatively, use my pmeventd (previously suspendd) from my pmutils
package. You get complete control over all PM events. The daemon sets
no policy (unlike apmd).
http://www.atnf.csiro.au/~rgooch/linux/
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/pmutils.tar.gz
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Grover, Andrew writes:
> A generalized interface is more work, and I see no
> benefit *right now*. We'll see when someone designs one, I guess.
If the whole world were ACPI, yes I would not see a benefit either,
but for PPC, UltraSPARC-III etc. systems there is going to be a gain.
These systems do power management in a way that is in many ways quite
different from the models provided by ACPI.
You can break the whole power management problem down to "here are
the levels of low-power provided by the hardware, here are the
idleness triggers that may be monitored". That's it, nothing more.
This is powerful enough to do all the things you could want a pm layer
to do:
1) CPU's have been in their idle threads for X percent of
of the past measurement quantum, half clock the processors.
2) The user has hit the "sleep" trigger, spin down the disks,
reduce clock the cpus, bus, PCI controller and PCI devices.
This kind of pm model with triggers and available low power states can
be used to solve problems PM was not designed to solve. For example,
if fans begin to fail and temperature indicates we might begin to
overheat, we can reduce clock the cpus to reduce the heat before doing
something more drastic like shutting the system down. Basically,
environment control problems can be expressed within this framework.
You get the idea. And none of it has anything to do with ACPI, Sun's
Ultra-III platform power management scheme, or what Apple uses in the
iBook.
This is the kind of model I like because it doesn't "look" like any
particular implementation of power management, it "is" power
management. I can plug any hardware PM scheme into that.
Later,
David S. Miller
[email protected]
[email protected] said:
> You can break the whole power management problem down to "here are the
> levels of low-power provided by the hardware, here are the idleness
> triggers that may be monitored". That's it, nothing more.
> This is powerful enough to do all the things you could want a pm layer
> to do:
>
> 1) CPU's have been in their idle threads for X percent of
> of the past measurement quantum, half clock the processors.
>
> 2) The user has hit the "sleep" trigger, spin down the disks,
> reduce clock the cpus, bus, PCI controller and PCI devices.
Often the 'sleep trigger' is an _absence_ of activity rather than anything
explicit like a button being pressed. You need inactivity timers, and events
which _reset_ those timers, on triggers like keyboard/touchscreen/serial
input, etc.
It's arguable that you can do that in userspace. Possibly - I'm not 100%
convinced of that. If you have many events which can reset many different
timers, the amount of traffic between kernel and user space just to reset
those timers may be quite high.
If an inactivity timer is implemented in userspace, with serial input being
one of the events that resets it, you're going to get a lot of wakeup/reset
events if you do a large download over that port.
It's possible that we could optimise that somehow, so we can avoid having
to implement PM timers in kernelspace. I'm not sure. Perhaps the wakeup
events could be on a separate queue, with no duplicates permitted, and the
PM daemon could poll that queue only when it's about to shoot one of its
timers.
For maximum efficiency, when receiving an event in sleep mode which isn't
supposed to wake the system, we should drop the event and go back to sleep
as quickly as possible. If you have to run userspace processes to make that
decision, it's not going to be particularly fast.
It may be sensible to have a simple policy engine in the kernel which
implement a policy provided by userspace. Some kind of simple state machine.
--
dwmw2
Hi!
> > You can break the whole power management problem down to "here are the
> > levels of low-power provided by the hardware, here are the idleness
> > triggers that may be monitored". That's it, nothing more.
> > This is powerful enough to do all the things you could want a pm layer
> > to do:
> >
> > 1) CPU's have been in their idle threads for X percent of
> > of the past measurement quantum, half clock the processors.
> >
> > 2) The user has hit the "sleep" trigger, spin down the disks,
> > reduce clock the cpus, bus, PCI controller and PCI devices.
>
> Often the 'sleep trigger' is an _absence_ of activity rather than anything
> explicit like a button being pressed. You need inactivity timers, and events
> which _reset_ those timers, on triggers like keyboard/touchscreen/serial
> input, etc.
I believe that at least thermal managment should be done in
kernelspace. You do not want to overheat your cpu because you
accidentally killed powerd, right?
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+