--pgp-sign-Multipart_Sat_Jul__7_16:12:23_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Sat, 7 Jul 2007 07:03:31 -0400, Allen Briggs wrote:
Subject: Re: Adding a new options to envstat (was: CVS commit: src/usr.sbin=
/envstat)
>=20
> On Fri, Jul 06, 2007 at 10:51:30PM +0200, Juan RP wrote:
> >=20
> > 2- Two or three persons wanted to show invalid sensors by default.
>=20
> Several people gave reasons why they wanted to show invalid sensors.

NOTE:  these are not "invalid sensors", but rather valid known and
supported sensors with _values_ that have been tagged as "invalid".


>  I
> think that at least some of those would have been happy with a '-a' or
> '-v' option to list them.  It would be consistent with other utilities,
> I think, to have a '-q' to suppress invalid sensors or a '-a' (all) or
> '-v' (verbose) to list them.

Well, if anything a "-q" or similar option parameter used to suppress
listing of sensors with invalid values would be the best option, but
IMNSHO it's not OK to suppress any known/supported sensor by default.

I really don't think a new command-line option is necessary though --
"grep -v" will do the same thing, and it's already available and working.

Besides, to the best of my understanding the original default output of
"envstat" always reported all known sensors, marking those with invalid
values with an asterisk; however the original "envstat -r" produced
output lacking mention of all sensors.  My original PR was simply to fix
"envstat -r" to produce matching output with all the same sensors being
shown as when "-r" was not used.  Now that row output is the default I
think it's even more important to have all known sensors reported (by
default at least).

Just to clarify in more excruciating detail in this forum, as I
explained in PR #36458 and its followups, a sensor with an invalid value
is, in many or even most cases, no different from a sensor with a valid
but out-of(-valid)-range value.

Given the way envsys(4) is structured and how it uses underlying drivers
which may themselves simply be interfaces to firmware running on some
co- or management processor, it is often impossible to know the
difference between a sensor which is out-of-range and being reported as
having an invalid value and one which is not valid because it isn't
connected.

It is often critical to see when a sensor suddenly has an invalid value,
just as it would be to see when a value wanders out of its valid range.
For example if a fan was connected and was reporting valid RPM values at
one point, but then somehow becomes "disconnected" and the BMC is no
longer reporting its value as valid, then I need to know that fact ASAP.
If there's a mouse chewing my wires then I need to set a trap!  :-)

So, all known/supported sensors really must be reported by default all
of the time, regardless of whether or not their values have been marked
as invalid -- it's effectively impossible for envstat(8) (or envsys(4)
or any of the underlying device drivers) to know the reason for a
sensor's value being reported as invalid and whether or not this has an
relevance to the user.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Sat_Jul__7_16:12:23_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: UC/m2wlgTYBvKh30dTgf2/e0aIqW8mR4

iQA/AwUBRo/zqGZ9cbd4v/R/EQJWJACg/VyvvMnOOA935nB1IJ/UDh2DI24AoPPG
f00dLTCBnqfmtDvLZL/nMJ6T
=EGUV
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sat_Jul__7_16:12:23_2007-1--