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?
> > >
>
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?
Because apmd is
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
[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
[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
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:
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
> 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
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
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).
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?
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
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
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
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
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
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).
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
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
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
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
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
> >
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
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
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,
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
[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
[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,
"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
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
> 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
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
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
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
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
"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
"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
> 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
>
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
> 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
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
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
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
"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
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
"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
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
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.
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
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
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
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
"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
"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.
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
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
"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
> 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.
>
>
"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
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
> 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
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
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
"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
"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
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
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
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
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
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.
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
"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
[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
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
"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
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
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
> 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.
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
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
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
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,
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
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
>
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);
>
>
> 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
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.
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
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
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
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
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
1 - 100 of 139 matches
Mail list logo
