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

Pietro Cerutti gahr at FreeBSD.org
Mon Sep 8 22:34:04 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Nate Lawson wrote:
| Pietro Cerutti wrote:
|> Nate Lawson wrote:
|> | 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.
|>
|> [snip xbatt-related stuff]
|>
|> | Let's keep this in usermode, where policy belongs.
|>
|> That's fine. Thanks for reviewing that!
|
| Thanks for helping with FreeBSD.  Hope you'll work on other stuff in the
| future.

Stay assured :)

- --
Pietro Cerutti
gahr at FreeBSD.org

PGP Public Key:
http://gahr.ch/pgp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEAREKAAYFAkjFqFEACgkQwMJqmJVx946SqgCgrmDAjzwZcRURJmspEu5178xt
4aAAoNi+PRH6adhJf3QpllLGXwfPEDzD
=y/OG
-----END PGP SIGNATURE-----


More information about the freebsd-acpi mailing list