sensors-detect

sensors-detect

[Jean Delvare]

Hello,

I contact you because you seem to be (one of the) packager(s) of
lm_sensors for Red Hat. We came across an issue you seem to have solved
in your package version 2.6.5-2. I'm actually refering to this:

* Fri Nov 29 2002 Phil Knirsch <pknirsch@redhat.com> 2.6.5-2
- Added patch to fix utf8 problem with sensors-detect.

Though we all agree there was a problem, and the patch solves it,
there's a question I'd like to ask: what makes you think the issue (for
reminder, a misuse of pack("C", $value);) is related to UTF?

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

sensors-detect

[Jean Delvare]

I've been adding support to sensor-detect for some chips we don't have a
driver for yet (LM82, LM86, LM90) and I plan to add some more in the
next few days. I think it's generally a good idea to detect many chips
even if we don't have drivers for them - and even if we know we won't
ever write one for some reason. In the first case, this let us know when
a given driver should be written through user repports. In the second
case, it may prevent misdetection of the chip as one we support.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

sensors-detect

[Mark D. Studebaker]

agreed - that's why we have a separate column in the new drivers page for
whether the chip is detected. you can put 'CVS' or a release number in that column too.

Jean Delvare wrote:
> I've been adding support to sensor-detect for some chips we don't have a
> driver for yet (LM82, LM86, LM90) and I plan to add some more in the
> next few days. I think it's generally a good idea to detect many chips
> even if we don't have drivers for them - and even if we know we won't
> ever write one for some reason. In the first case, this let us know when
> a given driver should be written through user repports. In the second
> case, it may prevent misdetection of the chip as one we support.
> 

sensors-detect

[Jean Delvare]

> > I think it's generally a good idea to detect
> > many chips even if we don't have drivers for them

> agreed - that's why we have a separate column in the new drivers page
> for whether the chip is detected. you can put 'CVS' or a release
> number in that column too.

Argh. I remember I removed this information at the time I cleaned up the
new drivers page. That's partly because I was thinking only really new
drivers (CVS) should be on that page, partly because the info was always
the same as in the "first release" column. About that, I agree that we
can leave recent drivers on that page even if they are already present
in the latest release.

I'll update the new drivers page today and leave drivers that were added
in 2.7.0 and 2.8.0 there. I'll move every other to the supported devices
pages, that I will update too.

Back to the use a revision number in the "detected" column, I think we
can live without it. I agree that users need to know from which version
a given chip is *supported*. But I don't think they care about the first
release since a chip is *detected*. Having his or her chip detected is
useless unless it's also supported by a driver. What's more, it's always
possible to run a recent sensors-detect on an older release of
lm_sensors, since the script is mostly independant, so someone
interested in chip detection will always want the very latest
sensors-detect anyway. If one really wants the
detected-since-this-release info, he/she can simply look at the CHANGES
file or the CVS logs.

So I think I won't bring the information back.

Also, I think I'll make the "supported devices" page look much like the
"new drivers page", which I find clearer.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/