kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8)

[Nate Lawson]

The following reply was made to PR kern/124223; it has been noted by GNATS.

From: Nate Lawson <nate at root.org>
To: Pietro Cerutti <gahr at FreeBSD.org>
Cc: bug-followup at FreeBSD.org, freebsd-acpi at FreeBSD.org
Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify  user-defined
  critical level via devd(8)
Date: Mon, 08 Sep 2008 15:04:02 -0700

 Pietro Cerutti wrote:
 > Nate Lawson wrote:
 > | There are a few problems with your approach.
 > |
 > | Critical status is already reported with a flag when usermode polls for
 > | the battery status:
 > |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) {
 > |>     if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) {
 > |>         sc->flags |= ACPI_BATT_STAT_CRITICAL;
 > |>         device_printf(dev, "critically low charge!\n");
 > |>     }
 > |> }
 > 
 > I agree. Critical level is already checked for in the cmbat module.
 > However, reporting is not done in a "standardized" way. My patch would
 > just like to add notification through devd.
 
 But it doesn't just add notification through devd.  It adds a thread,
 that separately polls for battery state and sends a notify through devd.
  If the user is running any battery app, there's a double poll for the
 same info.
 
 I subscribe to the design approach that where it makes sense to do
 something in usermode, don't do it in kernel mode.  In this case, the IO
 interface is poll-only, and any user app that is running can set its own
 policy for how to deal with the information it gets from polling.
 
 > I agree that userlevel utilities can e.g., retrieve the remaining
 > percent and set the critical level arbitrarily, but I anyway think that
 > a configurable level to be seen as critical by the OS could be a useful
 > addition.
 > 
 > I'm open to discussions about the best way to implement it (cmbat,
 > battery, ...?), if we get to an agreement that this could be a useful
 > feature :) Otherwise feel free to close the PR, as I can accept your
 > arguments.
 
 I think it would be better to work with the third-party apps to support
 configurable levels.  In xbatt:
 
     /* If battery life is short, ring a bell */
     if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) {
 
 ... and ...
 
       /* set gage color */
         if (displayType == Color) {
             if (life < 3) {
                 gage_color = "red";
             } else if (life < 5) {
                 gage_color = "yellow";
             }
         }
 
 These thresholds could easily be a command-line var or X resource.
 Let's keep this in usermode, where policy belongs.
 
 -- 
 Nate