Subject: Re: FYI: ENVSYS 2 ready
To: Juan RP <juan@xtrarom.org>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-kern
Date: 07/05/2007 18:57:16
On Fri, 6 Jul 2007 00:45:45 +0200
Juan RP <juan@xtrarom.org> wrote:

> On Thu, 5 Jul 2007 18:37:20 -0400
> "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
> 
> > I just booted the new code on my laptop, because I wanted to assess
> > the health of one of the batteries.  (Conclusion:  it's an
> > ex-battery; it's not just pining for the fjord prefects....)  I
> > noticed something missing compared with older ACPI envstats: it
> > doesn't display the battery manufacturer, serial number, etc.  
> 
> But you can see it at autoconf time, there's no point in printing this
> information every time you do envstat. That's why I removed this part.
> 
Ah, but I'm looking forward to the day when we can dynamically swap out
batteries...  (The old code got that part wrong, I should note; it only
read that data at boot time, as best I can tell.)

More generally -- only having that at boot time is a bad idea, for two
reasons.  First, if I want to write a program to track something, it's
easier to look at the output of envstat than to grep /var/run/dmesg.boot
for the field.  (Some versions of Windows, at least, track battery
behavior over time.)  In that vein, I should add, I'd like a '-q'
option to suppress descriptor output; just print the value.  Second, in
my view the low-level interface -- envstat or ENVSYS -- shouldn't make
decisions about what may or may not be needed at a higher level.  If
the data is there, it should be retrievable.  (I have no objection if
the filtering is described by, say, envsys.conf; that way, you can
usually filter uninteresting stuff, but still allow specialized
applications to get at it.)


		--Steve Bellovin, http://www.cs.columbia.edu/~smb