RE: Let init know user wants to shutdown

RE: Let init know user wants to shutdown

[Grover, Andrew]

[do we want to move this to linux-power?]

> From: John Fremlin [mailto:chief@bandits.org]
> > 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.

Re: Let init know user wants to shutdown

[Alan Cox]

> 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. 

Re: Let init know user wants to shutdown

[John Fremlin]

"Grover, Andrew" <andrew.grover@intel.com> 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

Re: Let init know user wants to shutdown

[John Fremlin]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: Let init know user wants to shutdown

[Alan Cox]

> 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

Re: Let init know user wants to shutdown

[John Fremlin]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: Let init know user wants to shutdown

[Alan Cox]

> 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)

Re: Let init know user wants to shutdown

[John Fremlin]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: Let init know user wants to shutdown

[Avery Pennarun]

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

Re: Let init know user wants to shutdown

[John Fremlin]

 Avery Pennarun <apenwarr@worldvisions.ca> 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

Next gen PM interface

[John Fremlin]

John Fremlin <chief@bandits.org> 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

Re: Next gen PM interface

[Alan Cox]

> 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)

Re: Next gen PM interface

[Patrick Mochel]

> > 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

Re: Next gen PM interface

[John Fremlin]

 Patrick Mochel <mochel@transmeta.com> 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

Re: Next gen PM interface

[John Fremlin]

 Patrick Mochel <mochel@transmeta.com> 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

Re: Next gen PM interface

[Patrick Mochel]

> > > >         (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

Re: Next gen PM interface

[John Fremlin]

Patrick Mochel <mochel@transmeta.com> 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

Re: Let init know user wants to shutdown

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Let init know user wants to shutdown

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Next gen PM interface

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Let init know user wants to shutdown

[John Fremlin]

 Pavel Machek <pavel@suse.cz> 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

Re: Let init know user wants to shutdown

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Let init know user wants to shutdown

[Jamie Lokier]

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

Re: Let init know user wants to shutdown

[John Fremlin]

Jamie Lokier <lk@tantalophile.demon.co.uk> 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

Re: Let init know user wants to shutdown

[Pavel Machek]

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

Re: Let init know user wants to shutdown

[Jamie Lokier]

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

Re: Let init know user wants to shutdown

[Richard Gooch]

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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Let init know user wants to shutdown

[John Fremlin]

Pavel Machek <pavel@suse.cz> 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?
> 
> No, this looks reasonable.

What do you think Stephen and Avery? Are you happy with this idea?

If anybody wants to test it, my latest pmevent patch will reject *all*
APM events it can. It would be easy to adapt that to turn on and off
with an ioctl. I am happy to do that if Stephen would accept
it. (Personally would like it if events were rejected by default but
that breaks backward compatibility and there is always someone who
would get bitten.)

The latest pmevent patch (v3) with various APM cleanups is available
at

        http://ape.n3.net/programs/linux/offbutton/download

Note that it currently shares no code with the pmpolicy patch.
For more information see

        http://ape.n3.net/programs/linux/offbutton/

-- 

	http://ape.n3.net