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?
> > >
>
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 d
[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 la
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 syste
> 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 interf
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/lin
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? A
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 so
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 blin
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 e
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 b
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
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
> > me
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
[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
"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, thoug
"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
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 m
> 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 pr
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 wit
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 acc
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
> 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 dri
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 singleus
"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
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
"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
> 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
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 eve
> 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
-
To unsubscribe from this list: send the line "u
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 ACP
"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 proce
> 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
[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.
>
> Deali
"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 sc
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 ha
> 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 solut
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 a
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
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
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 shut
"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 s
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.
> 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. Perha
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
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 ha
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 a
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, w
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 you
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
> doe
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
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
> 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 exce
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.
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
"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
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, And
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 ca
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)...
"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 righ
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
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 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
According to Kurt Roeckx:
> On Tue, Apr 10, 2001 at 11:20:24PM +, 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
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, 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
> > S
On Tue, Apr 10, 2001 at 11:20:24PM +, 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
>
>
On Tue, Apr 10, 2001 at 11:20:24PM +, 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
In article <9b04fo$9od$[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
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
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
not
70 matches
Mail list logo
