Subject: Re: power management and related concerns
From: Jan Danielsson <email@example.com>
Date: 07/01/2006 13:58:25
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
Garrett D'Amore wrote:
> Steven M. Bellovin wrote:
>> On Fri, 30 Jun 2006 17:28:15 -0700, "Garrett D'Amore"
>> <firstname.lastname@example.org> wrote:
>>> Well, I've made the mistake of looking at what we currently have in
>>> NetBSD. And comparing it with some real (our) hardware.
>>> There are few quick points for discussion:
>>> 1) there doesn't seem a clear way to indicate powerfail for a low
>>> battery condition in sysmon. Should I just be sending init some sign=
>>> 2) No way to indicate overtemp status either
>>> 3) Currently it isn't clear whether you should be registering with AP=
>>> sysmon, or something else for things like battery status, etc. It wo=
>>> be really, really good if drivers didn't have to do _both_ of these
>>> things. Can we maybe have a sysmon APM compatibility layer? (I gues=
>>> there are some userland apps that "know" about APM. Bletch.)
>>> 4) We need some userland tools to talk to sysmon in base, I think.=20
>>> (E.g. to query batteries, etc.)
>>> 5) In many respects, sysmon looks like a good start. I've coded a qu=
>>> power management driver for the Ultrabook IIi (okay, it was mostly a
>>> port from Solaris), and it basically works for things like lid switch=
>>> AC power cord un/plug, and power button.
>> I've been thinking similar thoughts. I have a paper design for (what =
>> had tentatively called) envstatd. The config file would look somethin=
>> like this:
>> acpibat0 <.04 /bin/shutdown -p now
>> temp=3Dacpitemp >70*2 /bin/shutdown -p now
>> where the *2 indicates that it has to happen twice in a row. A few mo=
>> frills, like shell variables for each config line -- the 'temp' means =
>> a script would be run with envstatd_temp set to the value. A | at the=
>> start of the command would create a pipeline that would be fed the val=
>> on stdin, to permit easy real-time graphing programs.
>> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> What you are talking about is the userland framework. Funny thing is,
> we have something kind of like this Tadpole's Solaris tree. NetBSD als=
> has powerd, which is a "start".
> I'm more concerned at the moment, about how the kernel code passes the
> raw data for these events to userland. Figuring out how to react to
> them in userland is probably somewhat easier - because it can more
> readily be simulated, and doesn't have to deal with 18 gazillion
> different kinds of power controllers.
> I would strongly, strongly prefer to avoid naming things "acpi" or
> "apm". A lot of real systems don't use anything like these, and it
> would be nice not to have to pretend your SPARC workstation was a PeeCe=
> to deal with power related events. :-)
savetreesd (some will think this is a spam daemon)
algored (a very dull daemon, but it is trying to save our environment)
Silly comments aside.. Will it be possible for the daemon to signal
back and say "Ok, sleeping is fine, just not *right now*. Call me back
I may want NetBSD to go to sleep after 10 minutes of inactivity,
unless I'm burning a DVD; then I do not want it to go to sleep until
that process is done.
Te audire non possum. Musa sapientum fixa est in aure.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (MingW32)
-----END PGP SIGNATURE-----