lkml.org 
[lkml]   [2001]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Let init know user wants to shutdown
From
Date
 "Grover, Andrew" <andrew.grover@intel.com> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.052 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site