Subject: Re: bin/36458 ("envstat -r" doesn't show what "envstat" shows)
To: None <gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,>
From: Juan RP <juan@xtrarom.org>
List: netbsd-bugs
Date: 07/03/2007 18:30:02
The following reply was made to PR bin/36458; it has been noted by GNATS.

From: Juan RP <juan@xtrarom.org>
To: gnats-bugs@NetBSD.org
Cc: "Greg A. Woods" <woods@planix.com>
Subject: Re: bin/36458 ("envstat -r" doesn't show what "envstat" shows)
Date: Tue, 3 Jul 2007 20:25:53 +0200

 On Tue,  3 Jul 2007 18:00:13 +0000 (UTC)
 "Greg A. Woods" <woods@planix.com> wrote:
 
 >  Well, I don't have access to much of a variety of systems with supported
 >  sensors yet, but if what you're saying is true then there's a huge pile
 >  of bogus or broken code somewhere else.
 >  
 >  On the systems I have access to my changes make the row mode output show
 >  _exactly_ the same stuff as the column mode output.
 
 I agree that envstat should show the same sensors in column and row mode.
   
 >  I don't really care which is wrong, but both modes really MUST show
 >  exactly the same set of sensors!  (and of course that set should be all
 >  the available sensors!)
 >  
 >  All I did was make the row-mode code work the same way as the column
 >  mode code, since on at least one of my systems my fix allows sensors
 >  which the motherboard manual state really should be there to appear just
 >  as they appear in the column mode, so either something's reading the
 >  valid flags wrong, or maybe they're not set right in the firmware, but
 >  either way the column mode shows them as expected while the row mode did
 >  not show them before my fix.
 > 
 >  Note there's also a strong argument to be made for showing sensors even
 >  when their values are claimed to be invalid (but of course giving a
 >  recognizable indication that their value is in fact invalid).  An
 >  invalid value is really nothing more than a value that is out of range
 >  and it's just as important for monitoring software to see invalid sensor
 >  values as it is for it to see valid values that are out of range.
 >  
 >  If a sensor itself is invalid (i.e. it isn't even supported in any way
 >  by the hardware), then I can see good reason for not reporting the
 >  sensor.  Obviously there can be an infinite number of invalid sensors
 >  and you can't report them all.
 
 You are confusing Indicator sensors with other kind of sensors. As I
 explained you before, Indicator sensors are there when something is
 enabled or in 'on' state, if they are disabled there's no need to show
 them.
 
 For example take a look at the acpiacad(4) driver. This driver shows
 the 'acpiacad0 connected' sensor if the AC Adapter is connected or
 the 'acpiacad0 disconnected' if the AC Adapter is disconnected.
 
 With your patch, acpiacad(4) would report:
 
 acpiacad0 connected: ON
 acpiacad0 disconnected: OFF
 
 And IMHO it's better what we do now, only show the Indicator sensor
 that has a value and is enabled.
 
 -- 
 Juan Romero Pardines	- The NetBSD Project
 http://plog.xtrarom.org	- NetBSD/pkgsrc news in Spanish