[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
    [do we want to move this to linux-power?]

    > From: John Fremlin []
    > > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:26    [W:0.026 / U:0.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site