[lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi all,

As announced last week, I released a first release candidate (rc1) of
lm-sensors 3.0.0. The API is supposedly OK now, so it's time for
application authors to try and port their applications to the new
library and send us feedback.

Important changes compared to lm-sensors 2.10:
* lm-sensors 3 only supports kernels 2.6.5 and later.
* It is now a user-space-only package, it no longer contains kernel
  drivers.
* The i2c tools have been moved to a separate package (surprisingly
  named i2c-tools).
* libsensors version was bumped to 4.0.0, as it has a completely new
  API we had to increase the .so version. This new library contains
  no chip-specific knowledge, it assumes that hardware monitoring
  drivers follow the standard sysfs interface.
* The "sensors" binary has temporarily been renamed to "sensors3", so
  that you can keep the old version around for comparison purpose. It
  will be renamed back to "sensors" just before lm-sensors 3.0.0 is
  released.
* sensors.conf is not fully compatible between the old and the new
  library. The lm-sensors 3 package includes a conversion script
  from the old format to the new one.

There's one remaining open task for lm-sensors 3.0.0:
http://www.lm-sensors.org/ticket/2174
Mark, this is yours. If you don't think you'll have the time to
implement it quickly, please move it to milestone 3.0.1.

lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to
keep signing the archives for the lm-sensors 3 series? If you want to
do it, please proceed. If you prefer that I take over, just say so and
I'll do it.

Notes to application authors:
* The new library has no chip-specific knowledge. As a result, the
  <sensors/chips.h> header file is gone.
* Pretty much all functions of the old API are gone or work
  differently. If you need to test for the new library in some
  configure script, sensors_get_features, sensors_get_all_subfeatures
  and sensors_get_subfeature are good candidates. Alternatively, you
  can test that the libsensors_version string starts with "3." or
  explicitly ask for libsensors.so.4.
* Reloading the configuration file with sensors_init() is no longer
  supported, you need to explicitly call sensors_cleanup() before you
  can call sensors_init() again.
* There's no porting guide available. The new API is so different from
  the old one that you're probably better looking at an application
  using the new API to get an idea how it works. It's not very
  difficult. The "sensors" and "sensord" applications that are part of
  the lm-sensors package have been ported to the new API already, so
  they are good examples. "sensors" in particular is very simple.

I've ported xsensors already, the patch is available here:
http://jdelvare.pck.nerim.net/sensors/xsensors-libsensors4.patch

I'll do the Freshmeat announcement tomorrow.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Philip Edelbrock]

[-- Attachment #1.1: Type: text/plain, Size: 418 bytes --]


On Sep 25, 2007, at 2:33 PM, Jean Delvare wrote:

>
> lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to
> keep signing the archives for the lm-sensors 3 series? If you want to
> do it, please proceed. If you prefer that I take over, just say so and
> I'll do it.


If you want to take over the signing, that's perfectly alright to  
me.  Might make more sense for you to be doing it anyway.


Phil


[-- Attachment #1.2: Type: text/html, Size: 1426 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> As announced last week, I released a first release candidate (rc1) of
> lm-sensors 3.0.0. The API is supposedly OK now, so it's time for
> application authors to try and port their applications to the new
> library and send us feedback.
> 
> Important changes compared to lm-sensors 2.10:
> * lm-sensors 3 only supports kernels 2.6.5 and later.
> * It is now a user-space-only package, it no longer contains kernel
>   drivers.
> * The i2c tools have been moved to a separate package (surprisingly
>   named i2c-tools).
> * libsensors version was bumped to 4.0.0, as it has a completely new
>   API we had to increase the .so version. This new library contains
>   no chip-specific knowledge, it assumes that hardware monitoring
>   drivers follow the standard sysfs interface.
> * The "sensors" binary has temporarily been renamed to "sensors3", so
>   that you can keep the old version around for comparison purpose. It
>   will be renamed back to "sensors" just before lm-sensors 3.0.0 is
>   released.
> * sensors.conf is not fully compatible between the old and the new
>   library. The lm-sensors 3 package includes a conversion script
>   from the old format to the new one.
> 
> There's one remaining open task for lm-sensors 3.0.0:
> http://www.lm-sensors.org/ticket/2174
> Mark, this is yours. If you don't think you'll have the time to
> implement it quickly, please move it to milestone 3.0.1.
> 
> lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to
> keep signing the archives for the lm-sensors 3 series? If you want to
> do it, please proceed. If you prefer that I take over, just say so and
> I'll do it.
> 
> Notes to application authors:
> * The new library has no chip-specific knowledge. As a result, the
>   <sensors/chips.h> header file is gone.
> * Pretty much all functions of the old API are gone or work
>   differently. If you need to test for the new library in some
>   configure script, sensors_get_features, sensors_get_all_subfeatures
>   and sensors_get_subfeature are good candidates. Alternatively, you
>   can test that the libsensors_version string starts with "3." or
>   explicitly ask for libsensors.so.4.
> * Reloading the configuration file with sensors_init() is no longer
>   supported, you need to explicitly call sensors_cleanup() before you
>   can call sensors_init() again.
> * There's no porting guide available. The new API is so different from
>   the old one that you're probably better looking at an application
>   using the new API to get an idea how it works. It's not very
>   difficult. The "sensors" and "sensord" applications that are part of
>   the lm-sensors package have been ported to the new API already, so
>   they are good examples. "sensors" in particular is very simple.
> 
> I've ported xsensors already, the patch is available here:
> http://jdelvare.pck.nerim.net/sensors/xsensors-libsensors4.patch
> 

Excellent work Jean! I've given this a test run on all my systems / test rigs 
and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
gome's sensors-applet as time permits. I'm afraid this will take a while as 
currently I'm very busy with stuff regarding the upcoming Fedora 8.

Talking about Fedora as soon as the development branch gets unfrozen for the 
F-9 cycle I'll put this new lmsensors in Fedora's development branch (together 
with patches apps), so that it can get a good amount of testing there, this 
won't happen for a while though.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Tue, 25 Sep 2007 14:45:44 -0700, Philip Edelbrock wrote:
> On Sep 25, 2007, at 2:33 PM, Jean Delvare wrote:
> > lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to
> > keep signing the archives for the lm-sensors 3 series? If you want to
> > do it, please proceed. If you prefer that I take over, just say so and
> > I'll do it.
> 
> If you want to take over the signing, that's perfectly alright to  
> me.  Might make more sense for you to be doing it anyway.

OK, I've signed the 3.0.0-rc1 archive. I'll let you sign the few last
2.10 releases we'll have though.

BTW, does anyone have an objection to switching to tar.bz2 for the next
3.0 releases? This seems to be pretty much the standard these days, and
that would save some disk space and bandwidth.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > As announced last week, I released a first release candidate (rc1) of
> > lm-sensors 3.0.0. The API is supposedly OK now, so it's time for
> > application authors to try and port their applications to the new
> > library and send us feedback.
> (...)
> Excellent work Jean! I've given this a test run on all my systems / test rigs 
> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
> gome's sensors-applet as time permits. I'm afraid this will take a while as 
> currently I'm very busy with stuff regarding the upcoming Fedora 8.

Great, thanks for the testing and thanks for working on application
patches. I'll try to take care about ksysguard myself, but I don't have
much time for this right now. net-snmp will have to be ported too. 

> Talking about Fedora as soon as the development branch gets unfrozen for the 
> F-9 cycle I'll put this new lmsensors in Fedora's development branch (together 
> with patches apps), so that it can get a good amount of testing there, this 
> won't happen for a while though.

Same for me, I'm waiting for openSuse 10.3 to be out before I start
packaging the new lm-sensors and i2c-tools for the next version.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Wed, 26 Sep 2007, Hans de Goede wrote:
> Excellent work Jean! I've given this a test run on all my systems / test rigs 
> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
> gome's sensors-applet as time permits. I'm afraid this will take a while as 
> currently I'm very busy with stuff regarding the upcoming Fedora 8.

When you do, *please* make sure to rip out any ibm-acpi/thinkpad-acpi procfs
support from those applications.  I have *never* seen perfect ibm-acpi
procfs parsing code in my life, and I tried to track down every app that
could do it... most of it is either thruly hideous, or broken in minor ways.

I don't want to see any app ever touching the ibm-acpi/thinkpad-acpi procfs
interface again.  That interface is crap, and needs to die.  And most of the
userspace code talking to it is even worse crap.

Also, please remember that sysfs hwmon may return -ENXIO (sensor not
available at this time) for some hotpluggable sensors, -EBUSY (try again
later), -EIO (failure to communicate with sensor) and some other crap that
should not cause an app to beat the bit bucket or pestering the user off
with dumb modal notifications of errors... I don't know how these propagate
through libsensors4, though.  Jean?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Henrique,

On Thu, 27 Sep 2007 14:53:12 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 26 Sep 2007, Hans de Goede wrote:
> > Excellent work Jean! I've given this a test run on all my systems / test rigs 
> > and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
> > gome's sensors-applet as time permits. I'm afraid this will take a while as 
> > currently I'm very busy with stuff regarding the upcoming Fedora 8.
> 
> When you do, *please* make sure to rip out any ibm-acpi/thinkpad-acpi procfs
> support from those applications.  I have *never* seen perfect ibm-acpi
> procfs parsing code in my life, and I tried to track down every app that
> could do it... most of it is either thruly hideous, or broken in minor ways.
> 
> I don't want to see any app ever touching the ibm-acpi/thinkpad-acpi procfs
> interface again.  That interface is crap, and needs to die.  And most of the
> userspace code talking to it is even worse crap.

The code may be ugly, however you can't ask people to drop support for
the old interface to ibm-acpi/thinkpad-acpi now while the new interface
is not even released. Your driver changes have not reached upstream yet,
and when they do, only lm-sensors 3 (of which there is only a RC
available for now) will support them, lm-sensors 2 doesn't. So you
should expect user-space applications to keep their support for the old
interface for some time, for compatibility reasons.

> Also, please remember that sysfs hwmon may return -ENXIO (sensor not
> available at this time) for some hotpluggable sensors, -EBUSY (try again
> later), -EIO (failure to communicate with sensor) and some other crap that
> should not cause an app to beat the bit bucket or pestering the user off
> with dumb modal notifications of errors... I don't know how these propagate
> through libsensors4, though.  Jean?

libsensors4 returns -SENSORS_ERR_KERNEL ("Kernel interface error")
if it can't read a value from a sysfs attribute file.
-SENSORS_ERR_ACCESS_R ("Can't read") would probably be preferable. It
doesn't read the actual error value returned by the underlying driver,
so all errors are handled the same way. The application could probably
check the value of errno to find out, but this is not documented, and
mixing proprietary error codes with standard ones could be confusing.

Do you think that we should allocate new proprietary error codes for
specific errors returned by the drivers on failed reads?

Rejected writes are silently ignored. Not good. We should detect these
and return some error code. I'll commit a fix for that.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Fri, 28 Sep 2007, Jean Delvare wrote:
> > When you do, *please* make sure to rip out any ibm-acpi/thinkpad-acpi procfs
> > support from those applications.  I have *never* seen perfect ibm-acpi
> > procfs parsing code in my life, and I tried to track down every app that
> > could do it... most of it is either thruly hideous, or broken in minor ways.
> > 
> > I don't want to see any app ever touching the ibm-acpi/thinkpad-acpi procfs
> > interface again.  That interface is crap, and needs to die.  And most of the
> > userspace code talking to it is even worse crap.
> 
> The code may be ugly, however you can't ask people to drop support for
> the old interface to ibm-acpi/thinkpad-acpi now while the new interface
> is not even released. Your driver changes have not reached upstream yet,
> and when they do, only lm-sensors 3 (of which there is only a RC
> available for now) will support them, lm-sensors 2 doesn't. So you
> should expect user-space applications to keep their support for the old
> interface for some time, for compatibility reasons.

I am assuming that any distro that is going to change stuff for lm-sensors
3.0.0 ahead of upstream will also ship with lm-sensors 3.0.0 (so userland
support will be there), and a new enough kernel in their next stable
release.  If I am wrong, then yes, one should not remove old
ibm-acpi/thinkpad-acpi procfs support.

> libsensors4 returns -SENSORS_ERR_KERNEL ("Kernel interface error")
> if it can't read a value from a sysfs attribute file.
> -SENSORS_ERR_ACCESS_R ("Can't read") would probably be preferable. It
> doesn't read the actual error value returned by the underlying driver,
> so all errors are handled the same way. The application could probably
> check the value of errno to find out, but this is not documented, and
> mixing proprietary error codes with standard ones could be confusing.
> 
> Do you think that we should allocate new proprietary error codes for
> specific errors returned by the drivers on failed reads?

I think we should differentiate ENXIO (sensor is not there right now) from
EIO (real IO error).  We can tack missing sysfs attributes along with ENXIO
as they are about the same thing, I think.  I don't know about what should
be done on EBUSY and EINTR/EAGAIN.  Probably the lib should retry by itself
on EINTR/EAGAIN (if it doesn't do it already -- I didn't read the code), and
just return an error on EBUSY.

> Rejected writes are silently ignored. Not good. We should detect these
> and return some error code. I'll commit a fix for that.

Yeah, we definately need to know in userspace if a write fails, and often we
need to know why, too.  I can think of at least three classes of errors to
differentiate for userland: "not there (file not found and ENXIO)", IO
errors, and "permission denied" errors.  EINTR/EAGAIN should be handled by
the lib itself, I think.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Fri, 28 Sep 2007 17:13:35 -0300, Henrique de Moraes Holschuh wrote:
> I am assuming that any distro that is going to change stuff for lm-sensors
> 3.0.0 ahead of upstream will also ship with lm-sensors 3.0.0 (so userland
> support will be there), and a new enough kernel in their next stable
> release.  If I am wrong, then yes, one should not remove old
> ibm-acpi/thinkpad-acpi procfs support.

Your assumptions are about right, however the added support for
lm-sensors 3.0.0 will be sent upstream quickly, while a patch removing
support for the old interface can't be sent upstream, so distributions
would have to maintain it forever. My experience is that
distributions avoid that kind of patch and extra work as much as
possible, especially when this doesn't add significant value (the extra
code is simply unused).

> > libsensors4 returns -SENSORS_ERR_KERNEL ("Kernel interface error")
> > if it can't read a value from a sysfs attribute file.
> > -SENSORS_ERR_ACCESS_R ("Can't read") would probably be preferable. It
> > doesn't read the actual error value returned by the underlying driver,
> > so all errors are handled the same way. The application could probably
> > check the value of errno to find out, but this is not documented, and
> > mixing proprietary error codes with standard ones could be confusing.
> > 
> > Do you think that we should allocate new proprietary error codes for
> > specific errors returned by the drivers on failed reads?
> 
> I think we should differentiate ENXIO (sensor is not there right now) from
> EIO (real IO error).

ENXIO should probably not be returned in the first place. Missing,
disabled or otherwise non-working sensors are reported through
fooN_fault files. When a fault is reported, user-space doesn't make use
of the (invalid or missing) input sensor value.

>                       We can tack missing sysfs attributes along with ENXIO
> as they are about the same thing, I think.

What "missing sysfs attributes"? libsensors gets the list of attributes
from sysfs, it doesn't expect any file (except "name") to be there. So,
unless files disappear afterwards, attributes can't be missing.

>                                             I don't know about what should
> be done on EBUSY and EINTR/EAGAIN.  Probably the lib should retry by itself
> on EINTR/EAGAIN (if it doesn't do it already -- I didn't read the code), and
> just return an error on EBUSY.

No, libsensors doesn't retry on EBUSY and EINTR/EAGAIN (as I said it
ignores the returned error code at the moment), and I don't think it
should. For how long would it wait? How many times would it retry
before giving up? If we are going to hard-code a policy in libsensors,
giving applications no control, then we might as well let the drivers
handle the retries by themselves, at least they know how much they
should wait between retries and when to give up depending on the
hardware (some drivers do that already, e.g. w83l785ts.)

Most monitoring applications are repeatedly polling the sensor values
every few seconds anyway, so if one measurement is missing, it will
probably be back on the next cycle. In other words, the retry mechanism
is already in place there, at the application level. Reimplementing it
in libsensors sounds wrong to me.

> > Rejected writes are silently ignored. Not good. We should detect these
> > and return some error code. I'll commit a fix for that.
> 
> Yeah, we definately need to know in userspace if a write fails, and often we
> need to know why, too.  I can think of at least three classes of errors to
> differentiate for userland: "not there (file not found and ENXIO)", IO
> errors, and "permission denied" errors.  EINTR/EAGAIN should be handled by
> the lib itself, I think.

I've committed my fix now. Permission denied is notified by
-SENSORS_ERR_KERNEL, other errors (including invalid value and I/O
error) are notified by -SENSORS_ERR_ACCESS_W. File not there is
unlikely (as explained above) and would be handled as a permission
problem.

So, from the above, it seems that what we both agree on is that a
separate error value for I/O errors would be needed. I'll work up a
patch implementing this.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Sat, 29 Sep 2007, Jean Delvare wrote:
> > I think we should differentiate ENXIO (sensor is not there right now) from
> > EIO (real IO error).
> 
> ENXIO should probably not be returned in the first place. Missing,
> disabled or otherwise non-working sensors are reported through
> fooN_fault files. When a fault is reported, user-space doesn't make use
> of the (invalid or missing) input sensor value.

This is not what I was told in this list in the past, which is why I return
ENXIO if one tries to access a hotplug thermal sensor in a thinkpad.  If the
EC would notify me when sensors come and go, I could add/remove the
attributes from sysfs and avoid the whole issue, but that's wishful
thinking.

I will look for the fooN_fault file docs, and implement that post haste,
then.

> >                       We can tack missing sysfs attributes along with ENXIO
> > as they are about the same thing, I think.
> 
> What "missing sysfs attributes"? libsensors gets the list of attributes
> from sysfs, it doesn't expect any file (except "name") to be there. So,
> unless files disappear afterwards, attributes can't be missing.

Sorry, what I meant is: some sensor that is exported in sysfs because it
*might* be in the hardware, and the driver can only tell if it is there or
not when it tries to access it (otherwise the driver would not have exported
the attribute to sysfs in the first place), and the sensor can come and go
at runtime without any sort of notification.

> No, libsensors doesn't retry on EBUSY and EINTR/EAGAIN (as I said it
> ignores the returned error code at the moment), and I don't think it
> should. For how long would it wait? How many times would it retry

Retrying on EINTR is pretty much needed, AFAIK.  If the library doesn't do
retries by itself, we must return a separate return code so that the library
user can.  I have never heard of EINTR being anything but a very temporary
condition, though.

EBUSY is something else.  That one can be quite permanent, so retrying on it
is best not done I suppose.

> before giving up? If we are going to hard-code a policy in libsensors,
> giving applications no control, then we might as well let the drivers
> handle the retries by themselves, at least they know how much they
> should wait between retries and when to give up depending on the
> hardware (some drivers do that already, e.g. w83l785ts.)

Drivers *do* often retry, if the hardware is busy.  But if they get a
signal, what should they do, then?  AFAIK at least for stuff like sysfs, one
is to return to userspace with EINTR to let userspace handle its signals,
and resubmit the request if it wants to.

My sources of EINTR in thinkpad-acpi are from mutex_lock_interruptible.

> Most monitoring applications are repeatedly polling the sensor values
> every few seconds anyway, so if one measurement is missing, it will
> probably be back on the next cycle. In other words, the retry mechanism
> is already in place there, at the application level. Reimplementing it
> in libsensors sounds wrong to me.

Even for EINTR?

> So, from the above, it seems that what we both agree on is that a
> separate error value for I/O errors would be needed. I'll work up a
> patch implementing this.

Thanks.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Sat, 29 Sep 2007 15:39:19 +0200, Jean Delvare wrote:
> So, from the above, it seems that what we both agree on is that a
> separate error value for I/O errors would be needed. I'll work up a
> patch implementing this.

I've committed a patch:
http://www.lm-sensors.org/changeset/4899

While testing it, I found that libsysfs will silently discard
attributes which return errors when being read. This means that an
attribute which returns an error at libsensors initialization time will
be forever missing, even if it can be successfully read again later.
This is no good. One more reason to get rid of libsysfs, I presume.

This also revealed that libsysfs reads the value from all attributes
when we do the device feature detection, even though we did not ask for
it and don't need the attribute values at all at this point. This
triggers a cache refresh at the device driver level (for most drivers
at least). No big deal for "sensors", but it's needlessly slowing down
"sensors -s". It might even have hidden driver bugs, as it means the
cache is always up-to-date when "sensors -s" is run, while drivers
should be able to cope with "sensors -s" when the cache is not yet
populated. Oh well, we really have to move away from libsysfs. I've
created a ticket in trac for that, it's scheduled for lm-sensors 3.0.1:

http://www.lm-sensors.org/ticket/2262

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Henrique,

On Sat, 29 Sep 2007 21:56:18 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 29 Sep 2007, Jean Delvare wrote:
> > > I think we should differentiate ENXIO (sensor is not there right now) from
> > > EIO (real IO error).
> > 
> > ENXIO should probably not be returned in the first place. Missing,
> > disabled or otherwise non-working sensors are reported through
> > fooN_fault files. When a fault is reported, user-space doesn't make use
> > of the (invalid or missing) input sensor value.
> 
> This is not what I was told in this list in the past,

Sorry about that. I remember you asking about this problem some times
ago, and indeed I forgot to mention the "fault flag" mechanism. Well,
back then, fooN_fault files did not exist as such, but at least I
should have mentioned the concept. I simply did not realize that your
problem wasn't something completely new. My bad.

>                                                       which is why I return
> ENXIO if one tries to access a hotplug thermal sensor in a thinkpad.  If the
> EC would notify me when sensors come and go, I could add/remove the
> attributes from sysfs and avoid the whole issue, but that's wishful
> thinking.

libsensors wouldn't cope with that anyway, so I'm glad you're not doing
it. libsensors probes for available features at initialization time.
After that, the feature list doesn't change and applications can count
on it not changing. Of course, applications can run sensors_init()
again to get a fresher view of the hardware state, but this is pretty
expensive and not something that we want applications to do every other
second.

I agree it would be nice to have some form of hotplug support in
libsensors, not just for features being added or removed, but primarily
for _devices_ being added or removed. But I didn't have the time to
think about it. It was hard enough (and long enough) to get lm-sensors
3.0.0 ready to be released, I just can't do more myself.

> (...)
> Retrying on EINTR is pretty much needed, AFAIK.  If the library doesn't do
> retries by itself, we must return a separate return code so that the library
> user can.  I have never heard of EINTR being anything but a very temporary
> condition, though.

I just don't understand when -EINTR is supposed to be returned, sorry.
I don't think we have any hardware monitoring driver returning this at
the moment, do we?

> (...)
> Drivers *do* often retry, if the hardware is busy.  But if they get a
> signal, what should they do, then?  AFAIK at least for stuff like sysfs, one
> is to return to userspace with EINTR to let userspace handle its signals,
> and resubmit the request if it wants to.
> 
> My sources of EINTR in thinkpad-acpi are from mutex_lock_interruptible.

I really need you to explain in details how and why EINTR is generated
and what we are supposed to do with it. I can't implement anything in
libsensors as long as I don't understand what we are dealing with.
Ideally, you would even be writing the libsensors patch, as you seem to
understand the needs much better than I do.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Sun, 30 Sep 2007, Jean Delvare wrote:
> libsensors wouldn't cope with that anyway, so I'm glad you're not doing
> it. libsensors probes for available features at initialization time.

We better document that in the kernel docs, then.  Because AFAIK sysfs
interfaces are actually supposed to make those attributes come and go when
possible.

> After that, the feature list doesn't change and applications can count
> on it not changing. Of course, applications can run sensors_init()
> again to get a fresher view of the hardware state, but this is pretty
> expensive and not something that we want applications to do every other
> second.

I've seen that cause endless problems in ACPI drivers (thinkpad-acpi has
this issue on some deprecated codepaths).  It is really something to avoid
if at all possible.

> I agree it would be nice to have some form of hotplug support in
> libsensors, not just for features being added or removed, but primarily
> for _devices_ being added or removed. But I didn't have the time to
> think about it. It was hard enough (and long enough) to get lm-sensors
> 3.0.0 ready to be released, I just can't do more myself.

Fair enough.

> > Retrying on EINTR is pretty much needed, AFAIK.  If the library doesn't do
> > retries by itself, we must return a separate return code so that the library
> > user can.  I have never heard of EINTR being anything but a very temporary
> > condition, though.
> 
> I just don't understand when -EINTR is supposed to be returned, sorry.
> I don't think we have any hardware monitoring driver returning this at
> the moment, do we?

I know of thinkpad-acpi, but I didn't search for others.

> > (...)
> > Drivers *do* often retry, if the hardware is busy.  But if they get a
> > signal, what should they do, then?  AFAIK at least for stuff like sysfs, one
> > is to return to userspace with EINTR to let userspace handle its signals,
> > and resubmit the request if it wants to.
> > 
> > My sources of EINTR in thinkpad-acpi are from mutex_lock_interruptible.
> 
> I really need you to explain in details how and why EINTR is generated
> and what we are supposed to do with it. I can't implement anything in
> libsensors as long as I don't understand what we are dealing with.
> Ideally, you would even be writing the libsensors patch, as you seem to
> understand the needs much better than I do.

I am not completely sure I do understand EINTR, mind you.  But here's a
typical path in thinkpad-acpi that can return EINTR as per the
mutex_lock_interruptible documentation:

static ssize_t hotkey_mask_show(struct device *dev,
                           struct device_attribute *attr,
                           char *buf)
{
        int res;

        res = mutex_lock_interruptible(&hotkey_mutex);
        if (res < 0)
                return res;
        res = hotkey_mask_get();
        mutex_unlock(&hotkey_mutex);

        return (res)?
                res : snprintf(buf, PAGE_SIZE, "0x%08x\n", hotkey_mask);
}

It may return -EINTR from mutex_lock_interruptible, or -EIO from
hotkey_mask_get (a function internal to thinkpad-acpi).

AFAIK, all cases I have seen for EINTR on the kernel allow one to do
something like this in userspace:

rc = -EINTR;
while (rc = -EINTR) {
	(check if any of our signal handlers have signalled that a signal
         was receivied, e.g. sigterm)
	(kernel operation that can return EINTR);
}

Because EINTR is something that is one-shot.  You get it when a signal is
delivered, and that's it.  Many syscalls can even be told to restart
themselves in case of an EINTR (but I don't know much about that, sorry).

Thinking a bit more about it, it looks to me like libsensors4 needs to be
able to pass EINTR down the chain, and must let its user (the application)
do the retries.  So, as you said, no retries within libsensors4... but we
need an extra status code for EINTR.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Henrique,

On Sun, 30 Sep 2007 11:54:29 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 30 Sep 2007, Jean Delvare wrote:
> > libsensors wouldn't cope with that anyway, so I'm glad you're not doing
> > it. libsensors probes for available features at initialization time.
> 
> We better document that in the kernel docs, then.

Send a patch?

>                                                    Because AFAIK sysfs
> interfaces are actually supposed to make those attributes come and go when
> possible.

According to what standard?

> > After that, the feature list doesn't change and applications can count
> > on it not changing. Of course, applications can run sensors_init()
> > again to get a fresher view of the hardware state, but this is pretty
> > expensive and not something that we want applications to do every other
> > second.
> 
> I've seen that cause endless problems in ACPI drivers (thinkpad-acpi has
> this issue on some deprecated codepaths).  It is really something to avoid
> if at all possible.

I don't understand you. What should be avoided exactly?

> > > (...)
> > > Drivers *do* often retry, if the hardware is busy.  But if they get a
> > > signal, what should they do, then?  AFAIK at least for stuff like sysfs, one
> > > is to return to userspace with EINTR to let userspace handle its signals,
> > > and resubmit the request if it wants to.
> > > 
> > > My sources of EINTR in thinkpad-acpi are from mutex_lock_interruptible.
> > 
> > I really need you to explain in details how and why EINTR is generated
> > and what we are supposed to do with it. I can't implement anything in
> > libsensors as long as I don't understand what we are dealing with.
> > Ideally, you would even be writing the libsensors patch, as you seem to
> > understand the needs much better than I do.
> 
> I am not completely sure I do understand EINTR, mind you.  But here's a
> typical path in thinkpad-acpi that can return EINTR as per the
> mutex_lock_interruptible documentation:
> 
> static ssize_t hotkey_mask_show(struct device *dev,
>                            struct device_attribute *attr,
>                            char *buf)
> {
>         int res;
> 
>         res = mutex_lock_interruptible(&hotkey_mutex);
>         if (res < 0)
>                 return res;
>         res = hotkey_mask_get();
>         mutex_unlock(&hotkey_mutex);
> 
>         return (res)?
>                 res : snprintf(buf, PAGE_SIZE, "0x%08x\n", hotkey_mask);
> }
> 
> It may return -EINTR from mutex_lock_interruptible, or -EIO from
> hotkey_mask_get (a function internal to thinkpad-acpi).
> 
> AFAIK, all cases I have seen for EINTR on the kernel allow one to do
> something like this in userspace:
> 
> rc = -EINTR;
> while (rc = -EINTR) {
> 	(check if any of our signal handlers have signalled that a signal
>          was receivied, e.g. sigterm)
> 	(kernel operation that can return EINTR);
> }
> 
> Because EINTR is something that is one-shot.  You get it when a signal is
> delivered, and that's it.  Many syscalls can even be told to restart
> themselves in case of an EINTR (but I don't know much about that, sorry).
> 
> Thinking a bit more about it, it looks to me like libsensors4 needs to be
> able to pass EINTR down the chain, and must let its user (the application)
> do the retries.  So, as you said, no retries within libsensors4... but we
> need an extra status code for EINTR.

Why are you using mutex_lock_interruptible() rather than just
mutex_lock() as all the other hwmon drivers do?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Wed, 03 Oct 2007, Jean Delvare wrote:
> On Sun, 30 Sep 2007 11:54:29 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 30 Sep 2007, Jean Delvare wrote:
> > > libsensors wouldn't cope with that anyway, so I'm glad you're not doing
> > > it. libsensors probes for available features at initialization time.
> > 
> > We better document that in the kernel docs, then.
> 
> Send a patch?

Will do, later.

> > interfaces are actually supposed to make those attributes come and go when
> > possible.
> 
> According to what standard?

I'd have to hunt it down. I'll see if I can find where I got that from.

> > > After that, the feature list doesn't change and applications can count
> > > on it not changing. Of course, applications can run sensors_init()
> > > again to get a fresher view of the hardware state, but this is pretty
> > > expensive and not something that we want applications to do every other
> > > second.
> > 
> > I've seen that cause endless problems in ACPI drivers (thinkpad-acpi has
> > this issue on some deprecated codepaths).  It is really something to avoid
> > if at all possible.
> 
> I don't understand you. What should be avoided exactly?

Stuff that will only work if the device is present at boot up/module
load/library init.

> > > > (...)
> > > > Drivers *do* often retry, if the hardware is busy.  But if they get a
> > > > signal, what should they do, then?  AFAIK at least for stuff like sysfs, one
> > > > is to return to userspace with EINTR to let userspace handle its signals,
> > > > and resubmit the request if it wants to.
> > > > 
> > > > My sources of EINTR in thinkpad-acpi are from mutex_lock_interruptible.
[...]
> > Because EINTR is something that is one-shot.  You get it when a signal is
> > delivered, and that's it.  Many syscalls can even be told to restart
> > themselves in case of an EINTR (but I don't know much about that, sorry).
> > 
> > Thinking a bit more about it, it looks to me like libsensors4 needs to be
> > able to pass EINTR down the chain, and must let its user (the application)
> > do the retries.  So, as you said, no retries within libsensors4... but we
> > need an extra status code for EINTR.
> 
> Why are you using mutex_lock_interruptible() rather than just
> mutex_lock() as all the other hwmon drivers do?

Because I don't want to get anything stuck in D state and not responding to
signals.  Apart from bugs in thinkpad-acpi or ACPI subsystem that could
cause weirdness, there is also the case where an application wants to use
timers and I see no reason to interfere with that.

It is extremely easy to do kernel-side, it looks like the safer and more
friendly-to-your-neighbours path, and userspace is supposed to be able to
deal with syscalls returning EINTR, so why not sysfs operations?  Or did I
get the whole idea incorrectly?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Wed, 3 Oct 2007 08:38:41 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 03 Oct 2007, Jean Delvare wrote:
> > On Sun, 30 Sep 2007 11:54:29 -0300, Henrique de Moraes Holschuh wrote:
> > > On Sun, 30 Sep 2007, Jean Delvare wrote:
> > > > After that, the feature list doesn't change and applications can count
> > > > on it not changing. Of course, applications can run sensors_init()
> > > > again to get a fresher view of the hardware state, but this is pretty
> > > > expensive and not something that we want applications to do every other
> > > > second.
> > > 
> > > I've seen that cause endless problems in ACPI drivers (thinkpad-acpi has
> > > this issue on some deprecated codepaths).  It is really something to avoid
> > > if at all possible.
> > 
> > I don't understand you. What should be avoided exactly?
> 
> Stuff that will only work if the device is present at boot up/module
> load/library init.

Libsensors has worked that way for 9 years and nobody ever complained
about that particular point or even suggested that it could cause
problem or should be improved. As far as I can see, letting chips or
features go away after initialization time would require a major
redesign of the libsensors API. Such a redesign is not scheduled before
2015, and again I don't have the time for that anyway. Whoever wants
this to work, get to work on it by him/herself.

> > Why are you using mutex_lock_interruptible() rather than just
> > mutex_lock() as all the other hwmon drivers do?
> 
> Because I don't want to get anything stuck in D state and not responding to
> signals.  Apart from bugs in thinkpad-acpi or ACPI subsystem that could
> cause weirdness, there is also the case where an application wants to use
> timers and I see no reason to interfere with that.

Stuck in D state? I don't understand. Won't the signal simply be
delayed until the lock is released?

> It is extremely easy to do kernel-side, it looks like the safer and more
> friendly-to-your-neighbours path, and userspace is supposed to be able to
> deal with syscalls returning EINTR, so why not sysfs operations?  Or did I
> get the whole idea incorrectly?

I don't know. I was asking simply because this has never been a
problem in the past, so I was curious why your driver was different,
or, as it turns out, why applications would start doing things that
they seemingly weren't doing before. I guess that I won't understand
why all this complexity is needed until you can present a real-world
case where these events you describe really happen. For now, I will
just wait for you to send patches if you think they are needed.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Henrique de Moraes Holschuh]

On Thu, 04 Oct 2007, Jean Delvare wrote:
> > Stuff that will only work if the device is present at boot up/module
> > load/library init.
> 
> Libsensors has worked that way for 9 years and nobody ever complained
> about that particular point or even suggested that it could cause

Fair enough.  We just document it and go ahead.  If we ever meet something
that *really* needs it, we reconsider.

> > > Why are you using mutex_lock_interruptible() rather than just
> > > mutex_lock() as all the other hwmon drivers do?
> > 
> > Because I don't want to get anything stuck in D state and not responding to
> > signals.  Apart from bugs in thinkpad-acpi or ACPI subsystem that could
> > cause weirdness, there is also the case where an application wants to use
> > timers and I see no reason to interfere with that.
> 
> Stuck in D state? I don't understand. Won't the signal simply be
> delayed until the lock is released?

The point is, what if the lock is NOT released (for a long time/at all)?
There would be no need for mutex_lock_interruptible to exist if that was not
an issue.  The real question is, could this happen in thinkpad-acpi or other
hwmon chip drivers?

Of course, locks not being released are the sign of huge bugs on most of
hwmon that do operations that are bounded and fast in the first place, but
for complex drivers that call into the ACPI interpretor, that is not so
clear.

There is also the (probably quite minor) issue of latency.  While I can't
protect the full path properly (ACPI doesn't return the equivalent to EINTR,
so I end up doing what libsensors do if it gets an EINTR: it becomes an IO
error, and what the appplication gets in the end is an IO error, which it
won't retry), at least it means that most concurrent access to the sensors
interface in thinkpad-acpi will be protected against huge delays caused by
the ACPI serialization from letting signals get delivered.

By using mutex_lock_interruptible I just don't have to worry at all about
all those problems, as signals will not be too delayed because of my code.
Other code might do it, but that's outside my control.

So far I have looked at mutex_lock as something to use only when you cannot
use mutex_lock_interruptible (e.g. you have no way to return an error to
userspace at that stage).

Note that this is in part based on the fact that open/read/write operations
DO return EINTR, which glibc passes along back to the caller, so anything in
userspace that calls them in generic files/pipes/devices/sockets already has
to handle it (this is not the case of libsensors, of course -- libsensors
only talks to hwmon).

> > It is extremely easy to do kernel-side, it looks like the safer and more
> > friendly-to-your-neighbours path, and userspace is supposed to be able to
> > deal with syscalls returning EINTR, so why not sysfs operations?  Or did I
> > get the whole idea incorrectly?
> 
> I don't know. I was asking simply because this has never been a
> problem in the past, so I was curious why your driver was different,
> or, as it turns out, why applications would start doing things that
> they seemingly weren't doing before. I guess that I won't understand
> why all this complexity is needed until you can present a real-world
> case where these events you describe really happen. For now, I will
> just wait for you to send patches if you think they are needed.

I'd send the patches, yes.  But so far, I could not make heads-and-tails of
the libsensors code.  I am studying it.  I will have more time after the
merge window for 2.6.24 closes.

As for proving to you that this complexity is needed, well, I don't have any
latency-sensitive loads here, nor do I play with real-time audio.  But I
will be sure to tell you if I meet an easily reproducible scenario involving
libsensors.  I *know* first hand of such scenarios when dealing, e.g., with
/dev/hwrandom, which stalls for long times on slow hardware rngs.  But even
ACPI EC access is not supposed to stall for that long unless it is broken...

And I am certainly not advocating that other drivers go around doing
mutex_lock_interruptible if they know they don't need it.  I'd just like
libsensors4 to allow drivers who do want to, to be able to return EINTR.

One hwmon driver which is *slow* like all heck, at least the last time I
tried it about two years ago, is the sensors driver for IPMI BMCs.  That one
might have a better case for returning EINTR...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Henrique,

On Thu, 4 Oct 2007 09:49:30 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 04 Oct 2007, Jean Delvare wrote:
> > Stuck in D state? I don't understand. Won't the signal simply be
> > delayed until the lock is released?
> 
> The point is, what if the lock is NOT released (for a long time/at all)?
> There would be no need for mutex_lock_interruptible to exist if that was not
> an issue.  The real question is, could this happen in thinkpad-acpi or other
> hwmon chip drivers?
> 
> Of course, locks not being released are the sign of huge bugs on most of
> hwmon that do operations that are bounded and fast in the first place, but
> for complex drivers that call into the ACPI interpretor, that is not so
> clear.

It really depends on what you consider a "long" time. Some hwmon
drivers can take the lock for one second (reading all the register
values at once), which qualifies as long in some contexts, sure. But
for a hardware monitoring applet, this seems reasonably short to me.

And yes, never-returning locks would be bugs, so we don't have to
consider this case.

> (...)
> I'd send the patches, yes.  But so far, I could not make heads-and-tails of
> the libsensors code.  I am studying it.  I will have more time after the
> merge window for 2.6.24 closes.

You're looking at the lm-sensors-3.0.0 branch, right? The library code
there is rather sane IMHO, in comparison to trunk ;) There's not much
you have to look at: sensors_read_sysfs_attr() and
sensors_write_sysfs_attr() in lib/sysfs.c, and sensors_get_value() and
sensors_set_value() in lib/access.c. And then error.h and error.c if
you need to add error codes. And that's about it, I think.

> As for proving to you that this complexity is needed, well, I don't have any
> latency-sensitive loads here, nor do I play with real-time audio.  But I
> will be sure to tell you if I meet an easily reproducible scenario involving
> libsensors.  I *know* first hand of such scenarios when dealing, e.g., with
> /dev/hwrandom, which stalls for long times on slow hardware rngs.  But even
> ACPI EC access is not supposed to stall for that long unless it is broken...

Maybe it's just me missing the point, but I don't really see how
real-time audio fits in the picture. Non-interruptible locks don't
block your entire system, just the process in question, i.e. in our
case the application which is using libsensors. So my impression is
that having hwmon drivers return -EINTR rather than delaying signals
only matters if the same application that is using libsensors also
needs to do low-latency work. I don't know of any such application,
which is why I think we don't care.

Also worth reminding is the fact that a non-waiting call to
sensors_get_value() may take 1 second for some drivers. So if you are
worried about latency for the waiting case, you are most probably as
much worried about the non-waiting case. This pretty much forbids
mixing time-critical tasks with libsensors as far as I can see.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 1067 bytes --]

On Thu, Sep 27, 2007 at 04:35:30PM +0200, Jean Delvare wrote:
> On Tue, 25 Sep 2007 14:45:44 -0700, Philip Edelbrock wrote:
> > On Sep 25, 2007, at 2:33 PM, Jean Delvare wrote:
> > > lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to
> > > keep signing the archives for the lm-sensors 3 series? If you want to
> > > do it, please proceed. If you prefer that I take over, just say so and
> > > I'll do it.
> > 
> > If you want to take over the signing, that's perfectly alright to  
> > me.  Might make more sense for you to be doing it anyway.
> 
> OK, I've signed the 3.0.0-rc1 archive. I'll let you sign the few last
> 2.10 releases we'll have though.
> 
> BTW, does anyone have an objection to switching to tar.bz2 for the next
> 3.0 releases? This seems to be pretty much the standard these days, and
> that would save some disk space and bandwidth.

Since you copied me explictely on this one: No objections, of
course. We're offering bz2 (and not gz) for the automated snapshots
already BTW.
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
> Excellent work Jean! I've given this a test run on all my systems / test rigs 
> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
> gome's sensors-applet as time permits. I'm afraid this will take a while as 
> currently I'm very busy with stuff regarding the upcoming Fedora 8.

Any news on this? I am more or less waiting for this to happen before
we can release lm-sensors 3.0.0 final.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
>> Excellent work Jean! I've given this a test run on all my systems / test rigs 
>> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
>> gome's sensors-applet as time permits. I'm afraid this will take a while as 
>> currently I'm very busy with stuff regarding the upcoming Fedora 8.
> 
> Any news on this? I am more or less waiting for this to happen before
> we can release lm-sensors 3.0.0 final.
> 

I'll keep this mail in my todo list and start doing some testing as time 
permits. I have vacation next week, so I should be able todo this somewhere 
next week.

Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Aurelien Jarno]

Jean Delvare a écrit :
> Hi Hans,
> 
> On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
>> Excellent work Jean! I've given this a test run on all my systems / test rigs 
>> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
>> gome's sensors-applet as time permits. I'm afraid this will take a while as 
>> currently I'm very busy with stuff regarding the upcoming Fedora 8.
> 
> Any news on this? I am more or less waiting for this to happen before
> we can release lm-sensors 3.0.0 final.
> 

I have just given a try. It works nicely here.

However I have a remark to ease the transition from version 2.x.x to
version 3.0.0: it is currently possible to have the two libraries
installed, but they both use the same configuration file. What about
having different config files for the two versions (e.g. sensors.conf
and sensors3.conf) ?

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Aurelien,

On Thu, 18 Oct 2007 10:18:16 +0200, Aurelien Jarno wrote:
> Jean Delvare a écrit :
> > Any news on this? I am more or less waiting for this to happen before
> > we can release lm-sensors 3.0.0 final.
> 
> I have just given a try. It works nicely here.

Great, thanks for the testing and report.

> However I have a remark to ease the transition from version 2.x.x to
> version 3.0.0: it is currently possible to have the two libraries
> installed, but they both use the same configuration file. What about
> having different config files for the two versions (e.g. sensors.conf
> and sensors3.conf) ?

Technically speaking, the libraries themselves don't have default
configuration files. Applications do. That makes the matter only worse.

For openSuse, my plan was to get plain rid of lm-sensors 2 and all
applications using it as soon as possible, so that no such conflict
happens. I don't think we'll package libsensors v2.10.x in the next
release. I don't know what Hans' plans are for Fedora. Of course, if
you intend to guarantee backwards compatibility by shipping the old
libsensors for a longer time in Debian, then indeed you have a problem.

The fact that applications, rather than the library, set the default
configuration file name, means that it's essentially out of our control.
We could change sensors and sensord in lm-sensors 3.0.0 to use a
different default, but that won't solve the problem for all the 3rd
party applications out there. You'd need to change them all. Either the
authors do, or the packagers will have to.

If you want to use /etc/sensors3.conf as the default for applications
using lm-sensors 3 in Debian, there's nothing preventing you from doing
that. This doesn't really have to be done upstream. That being said, I
agree that it would become confusing if different distributions come up
with different naming schemes.

Coming to think about it, I think it's silly to have the default
configuration file name in applications. There's really no reason why
an application would want to use a different default, is there? So it
might be the right time to change this and put the default
configuration file name in libsensors. Calling sensors_init(NULL) would
use that default. It would make it easier to change the default if a
distribution wants to, and it would enforce a common default for
applications using the new library. Opinions?

I don't much like the idea of using /etc/sensors3.conf for lm-sensors
3. Soon enough, lm-sensors 2 will be history, sensors.conf will no
longer exist, and we'll be stuck with /etc/sensors3.conf. That's a bit
unaesthetic, isn't it? A slightly different approach would be to
use /etc/sensors3.conf if it exists, and /etc/sensors.conf otherwise
(as was done for the XFree86 configuration file from version 3.x to
version 4.x; remember?) This approach preserves compatibility with
existing installations and offers a nice upgrade path. But of course
this can only be (easily) implemented if the default is handled in
libsensors rather than in the applications themselves, as I proposed
above.

We have to decide ourselves quickly, as 3.0.0 is almost there now.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
>> Excellent work Jean! I've given this a test run on all my systems / test rigs 
>> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
>> gome's sensors-applet as time permits. I'm afraid this will take a while as 
>> currently I'm very busy with stuff regarding the upcoming Fedora 8.
> 
> Any news on this? I am more or less waiting for this to happen before
> we can release lm-sensors 3.0.0 final.
> 

Okay,

I've ported my first application over: gkrellm. gkrellm only uses the main 
featuree (_input values) so I instinctively wrote this:

	while ((feature = sensors_get_features(name, &nr1))) {
		/* ..... */
		result = sensors_get_value(name, feature->number, &val);

Which to my surprise doesn't work I now know this should be:
	while ((feature = sensors_get_features(name, &nr1))) {
		/* ..... */
		result = sensors_get_value(name,
			sensors_get_subfeature(name,                             				feature, 
SENSORS_SUBFEATURE_IN_INPUT),
			feature->number, &val);

Which must be put in a switch statement on feature->type to put in 
SENSORS_SUBFEATURE_IN_INPUT / SENSORS_SUBFEATURE_FAN_INPUT / 
SENSORS_SUBFEATURE_TEMP_INPUT

Ideally my first naive code should just work for simple applications which only 
want to read the main / _input feature, I haven't checked yet, but I think 
making my initial code work, doesn't match well with the current libsensors 
structure, so how about adding an "int input_subfeature_number" to the
sensors_feature struct, so that my original code will work like this:

	while ((feature = sensors_get_features(name, &nr1))) {
		/* ..... */
		result = sensors_get_value(name,
		 	feature->input_subfeature_number, &val);


Or alternatively a sensors_get_main_value(name, feature, &val) function?

Besides that adding a define to sensors.h which can be tested to find out 
against which libsensors version code is compiling would be a good idea too.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Fri, 19 Oct 2007 22:18:02 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
> >> Excellent work Jean! I've given this a test run on all my systems / test rigs 
> >> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
> >> gome's sensors-applet as time permits. I'm afraid this will take a while as 
> >> currently I'm very busy with stuff regarding the upcoming Fedora 8.
> > 
> > Any news on this? I am more or less waiting for this to happen before
> > we can release lm-sensors 3.0.0 final.
> 
> I've ported my first application over: gkrellm. gkrellm only uses the main 
> featuree (_input values) so I instinctively wrote this:
> 
> 	while ((feature = sensors_get_features(name, &nr1))) {
> 		/* ..... */
> 		result = sensors_get_value(name, feature->number, &val);
> 
> Which to my surprise doesn't work I now know this should be:
> 	while ((feature = sensors_get_features(name, &nr1))) {
> 		/* ..... */
> 		result = sensors_get_value(name,
> 			sensors_get_subfeature(name, feature, SENSORS_SUBFEATURE_IN_INPUT),
> 			feature->number, &val);
> 
> Which must be put in a switch statement on feature->type to put in 
> SENSORS_SUBFEATURE_IN_INPUT / SENSORS_SUBFEATURE_FAN_INPUT / 
> SENSORS_SUBFEATURE_TEMP_INPUT
> 
> Ideally my first naive code should just work for simple applications which only 
> want to read the main / _input feature, I haven't checked yet, but I think 
> making my initial code work, doesn't match well with the current libsensors 
> structure, 

Indeed. Features and subfeatures are now separate entities. When I
proposed to do that change a few months ago, nobody objected.

>            so how about adding an "int input_subfeature_number" to the
> sensors_feature struct, so that my original code will work like this:
> 
> 	while ((feature = sensors_get_features(name, &nr1))) {
> 		/* ..... */
> 		result = sensors_get_value(name,
> 		 	feature->input_subfeature_number, &val);
> 
> 
> Or alternatively a sensors_get_main_value(name, feature, &val) function?

First of all, please note that the main value in question may not
exist. Your code should be ready for it to happen.

My guess was that applications would need to switch on the feature type
anyway, as different types are usually displayed differently, so I
never considered this to be a problem. All of sensors, sensord and
xsensors do, I'm surprised that gkrellm doesn't. How does it display
the proper unit? How does it adjust the number of decimal places?

I am also surprised that you call sensors_get_value() directly in the
loop that discovers the features. Applications which display values
continuously (as opposed to sensors' one-shot) tend to store the
feature numbers at initialization time, and then call
sensors_get_value() on them directly without looping over
sensors_get_features() again.

Adding input_subfeature to struct sensors_subfeature is possible if it
helps you. It should be fairly easy. I'd just like to understand why
gkrellm's needs differ from the 3 applications I've ported myself.

sensors_get_main_value() doesn't sound like a good idea, as it would
require sensors_subfeatue anyway to be efficient.

> Besides that adding a define to sensors.h which can be tested to find out 
> against which libsensors version code is compiling would be a good idea too.

As the underlying build system needs to know what library will be used
(for proper linkage), I expected applications to deal with the
different versions on their own. But if you think that a #define in
sensors.h would help, just go ahead, that's fine with me.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Fri, 19 Oct 2007 22:18:02 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> On Wed, 26 Sep 2007 23:02:31 +0200, Hans de Goede wrote:
>>>> Excellent work Jean! I've given this a test run on all my systems / test rigs 
>>>> and it works great everywhere. I'll create patches for ksensors, gkrellm, and 
>>>> gome's sensors-applet as time permits. I'm afraid this will take a while as 
>>>> currently I'm very busy with stuff regarding the upcoming Fedora 8.
>>> Any news on this? I am more or less waiting for this to happen before
>>> we can release lm-sensors 3.0.0 final.
>> I've ported my first application over: gkrellm. gkrellm only uses the main 
>> featuree (_input values) so I instinctively wrote this:
>>
>> 	while ((feature = sensors_get_features(name, &nr1))) {
>> 		/* ..... */
>> 		result = sensors_get_value(name, feature->number, &val);
>>
>> Which to my surprise doesn't work I now know this should be:
>> 	while ((feature = sensors_get_features(name, &nr1))) {
>> 		/* ..... */
>> 		result = sensors_get_value(name,
>> 			sensors_get_subfeature(name, feature, SENSORS_SUBFEATURE_IN_INPUT),
>> 			feature->number, &val);
>>
>> Which must be put in a switch statement on feature->type to put in 
>> SENSORS_SUBFEATURE_IN_INPUT / SENSORS_SUBFEATURE_FAN_INPUT / 
>> SENSORS_SUBFEATURE_TEMP_INPUT
>>
>> Ideally my first naive code should just work for simple applications which only 
>> want to read the main / _input feature, I haven't checked yet, but I think 
>> making my initial code work, doesn't match well with the current libsensors 
>> structure, 
> 
> Indeed. Features and subfeatures are now separate entities. When I
> proposed to do that change a few months ago, nobody objected.
> 

I didn't understand back then that foo#_input would become a subfeature too, I 
thought that would be part of the main feature.

>>            so how about adding an "int input_subfeature_number" to the
>> sensors_feature struct, so that my original code will work like this:
>>
>> 	while ((feature = sensors_get_features(name, &nr1))) {
>> 		/* ..... */
>> 		result = sensors_get_value(name,
>> 		 	feature->input_subfeature_number, &val);
>>
>>
>> Or alternatively a sensors_get_main_value(name, feature, &val) function?
> 
> First of all, please note that the main value in question may not
> exist. Your code should be ready for it to happen.
> 

Do features that do have tresholds / other settings but no reading of the 
actual input exist?

> My guess was that applications would need to switch on the feature type
> anyway, as different types are usually displayed differently, so I
> never considered this to be a problem. All of sensors, sensord and
> xsensors do, I'm surprised that gkrellm doesn't. How does it display
> the proper unit? How does it adjust the number of decimal places?
> 

This is correct, there indeed is such a switch present, the code I postred was 
simplified for the discussion. Still needing to make an additional function 
call to get to the _input subfeature feels like a detour.

> I am also surprised that you call sensors_get_value() directly in the
> loop that discovers the features. Applications which display values
> continuously (as opposed to sensors' one-shot) tend to store the
> feature numbers at initialization time, and then call
> sensors_get_value() on them directly without looping over
> sensors_get_features() again.
> 

Actually you are right, the feature number gets remembered. (again I simplified 
the code).

> Adding input_subfeature to struct sensors_subfeature is possible if it
> helps you. It should be fairly easy. I'd just like to understand why
> gkrellm's needs differ from the 3 applications I've ported myself.
> 

Well it doesn't need it, but having it would make the code cleaner.

>> Besides that adding a define to sensors.h which can be tested to find out 
>> against which libsensors version code is compiling would be a good idea too.
> 
> As the underlying build system needs to know what library will be used
> (for proper linkage),

No it doesn't -lsensors will work for both linsensors3 and libsensors4 actually 
the ./configure check for libsensors in gkrellm works with both without 
modification (it checks for sensors/sensors.h && sensors_init()).

> I expected applications to deal with the
> different versions on their own. But if you think that a #define in
> sensors.h would help, just go ahead, that's fine with me.
> 

Well as explained above ./configure and the Makefiles don't need to know about 
the different versions, So only some code changes are needed, for which it 
would be nice if a #define is present to test for.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Sun, 21 Oct 2007 00:41:59 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Fri, 19 Oct 2007 22:18:02 +0200, Hans de Goede wrote:
> >> Ideally my first naive code should just work for simple applications which only 
> >> want to read the main / _input feature, I haven't checked yet, but I think 
> >> making my initial code work, doesn't match well with the current libsensors 
> >> structure, 
> > 
> > Indeed. Features and subfeatures are now separate entities. When I
> > proposed to do that change a few months ago, nobody objected.
> 
> I didn't understand back then that foo#_input would become a subfeature too, I 
> thought that would be part of the main feature.

That would have been a mess, I'm glad I didn't do that ;)

> (...)
> > First of all, please note that the main value in question may not
> > exist. Your code should be ready for it to happen.
> > 
> 
> Do features that do have tresholds / other settings but no reading of the 
> actual input exist?

As crazy as it sounds, yes, it exists. The early revisions of the
GL518SM report no voltage measurements, but have min and max voltage
settings and report alarms when those are crossed. Currently the
gl518sm driver reports 0 for the measurements in this case, but that's
not correct, it should not report them at all. I'll fix it.

> > My guess was that applications would need to switch on the feature type
> > anyway, as different types are usually displayed differently, so I
> > never considered this to be a problem. All of sensors, sensord and
> > xsensors do, I'm surprised that gkrellm doesn't. How does it display
> > the proper unit? How does it adjust the number of decimal places?
> 
> This is correct, there indeed is such a switch present, the code I postred was 
> simplified for the discussion. Still needing to make an additional function 
> call to get to the _input subfeature feels like a detour.
> 
> > I am also surprised that you call sensors_get_value() directly in the
> > loop that discovers the features. Applications which display values
> > continuously (as opposed to sensors' one-shot) tend to store the
> > feature numbers at initialization time, and then call
> > sensors_get_value() on them directly without looping over
> > sensors_get_features() again.
> 
> Actually you are right, the feature number gets remembered. (again I simplified 
> the code).
> 
> > Adding input_subfeature to struct sensors_subfeature is possible if it
> > helps you. It should be fairly easy. I'd just like to understand why
> > gkrellm's needs differ from the 3 applications I've ported myself.
> 
> Well it doesn't need it, but having it would make the code cleaner.

Well, if you already have a switch/case and store the subfeature
numbers, then a shortcut to get the input subfeature number doesn't save
that much, neither in terms of code nor in terms of speed. I don't
think it's worth adding.

> >> Besides that adding a define to sensors.h which can be tested to find out 
> >> against which libsensors version code is compiling would be a good idea too.
> > 
> > As the underlying build system needs to know what library will be used
> > (for proper linkage),
> 
> No it doesn't -lsensors will work for both linsensors3 and libsensors4 actually 
> the ./configure check for libsensors in gkrellm works with both without 
> modification (it checks for sensors/sensors.h && sensors_init()).

How do you deal with the case where both libsensors.so.3 and
libsensors.so.4 are available at link time?

> > I expected applications to deal with the
> > different versions on their own. But if you think that a #define in
> > sensors.h would help, just go ahead, that's fine with me.
> 
> Well as explained above ./configure and the Makefiles don't need to know about 
> the different versions, So only some code changes are needed, for which it 
> would be nice if a #define is present to test for.

As I said, just go ahead and add the #define you want. Feel free to add
the "same" #define to trunk if it helps.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Sun, 21 Oct 2007 00:41:59 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> On Fri, 19 Oct 2007 22:18:02 +0200, Hans de Goede wrote:
>>>> Ideally my first naive code should just work for simple applications which only 
>>>> want to read the main / _input feature, I haven't checked yet, but I think 
>>>> making my initial code work, doesn't match well with the current libsensors 
>>>> structure, 
>>> Indeed. Features and subfeatures are now separate entities. When I
>>> proposed to do that change a few months ago, nobody objected.
>> I didn't understand back then that foo#_input would become a subfeature too, I 
>> thought that would be part of the main feature.
> 
> That would have been a mess, I'm glad I didn't do that ;)
> 
>> (...)
>>> First of all, please note that the main value in question may not
>>> exist. Your code should be ready for it to happen.
>>>
>> Do features that do have tresholds / other settings but no reading of the 
>> actual input exist?
> 
> As crazy as it sounds, yes, it exists. The early revisions of the
> GL518SM report no voltage measurements, but have min and max voltage
> settings and report alarms when those are crossed. Currently the
> gl518sm driver reports 0 for the measurements in this case, but that's
> not correct, it should not report them at all. I'll fix it.
> 
>>> My guess was that applications would need to switch on the feature type
>>> anyway, as different types are usually displayed differently, so I
>>> never considered this to be a problem. All of sensors, sensord and
>>> xsensors do, I'm surprised that gkrellm doesn't. How does it display
>>> the proper unit? How does it adjust the number of decimal places?
>> This is correct, there indeed is such a switch present, the code I postred was 
>> simplified for the discussion. Still needing to make an additional function 
>> call to get to the _input subfeature feels like a detour.
>>
>>> I am also surprised that you call sensors_get_value() directly in the
>>> loop that discovers the features. Applications which display values
>>> continuously (as opposed to sensors' one-shot) tend to store the
>>> feature numbers at initialization time, and then call
>>> sensors_get_value() on them directly without looping over
>>> sensors_get_features() again.
>> Actually you are right, the feature number gets remembered. (again I simplified 
>> the code).
>>
>>> Adding input_subfeature to struct sensors_subfeature is possible if it
>>> helps you. It should be fairly easy. I'd just like to understand why
>>> gkrellm's needs differ from the 3 applications I've ported myself.
>> Well it doesn't need it, but having it would make the code cleaner.
> 
> Well, if you already have a switch/case and store the subfeature
> numbers, then a shortcut to get the input subfeature number doesn't save
> that much, neither in terms of code nor in terms of speed. I don't
> think it's worth adding.
> 

Okay, thats fine with me.

>>>> Besides that adding a define to sensors.h which can be tested to find out 
>>>> against which libsensors version code is compiling would be a good idea too.
>>> As the underlying build system needs to know what library will be used
>>> (for proper linkage),
>> No it doesn't -lsensors will work for both linsensors3 and libsensors4 actually 
>> the ./configure check for libsensors in gkrellm works with both without 
>> modification (it checks for sensors/sensors.h && sensors_init()).
> 
> How do you deal with the case where both libsensors.so.3 and
> libsensors.so.4 are available at link time?
> 

Well -lsensors will search for libsensors.so, which is a symlink to one of the 
two, I would expect this symlink to point to the same version as 
/usr/include/sensors/sensors.h is.

When talking distros, the symlinks usually reside in the -devel package. One 
can then make either the 2 -devel pakcages conflict, or put the symlink in a 
subdir of /usr/lib[64] and have a pkg-config file (which are usually versioned) 
and use pkg-config to add the correct -L/..... path to the LD_FLAGS.

This (symlinks in subdirs of /usr/lib, pkg-config) is how many libraries which 
are designed for parallel installs do it. In the case of lm_sensors the plan 
for Feodra is to switch to libsensors4 and just patch all users to move to the 
new API, I much rather spend some time writing patches for libsensors using 
apps, then spend time to make the 2 parallel installable. Also notice that as 
the 2 are inherently not paralell installable as the both want to install 
/usr/include/sensors/sensors.h


>>> I expected applications to deal with the
>>> different versions on their own. But if you think that a #define in
>>> sensors.h would help, just go ahead, that's fine with me.
>> Well as explained above ./configure and the Makefiles don't need to know about 
>> the different versions, So only some code changes are needed, for which it 
>> would be nice if a #define is present to test for.
> 
> As I said, just go ahead and add the #define you want. Feel free to add
> the "same" #define to trunk if it helps.
> 

Will do.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hans,

On Sun, 21 Oct 2007 21:13:35 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > How do you deal with the case where both libsensors.so.3 and
> > libsensors.so.4 are available at link time?
> 
> Well -lsensors will search for libsensors.so, which is a symlink to one of the 
> two, I would expect this symlink to point to the same version as 
> /usr/include/sensors/sensors.h is.

Ah, OK. I didn't realize this before, thanks for the clarification.

I somehow expected / hoped that it was possible to explicitly point ld
to a specific .so version, but apparently this isn't the case.

> When talking distros, the symlinks usually reside in the -devel package. One 
> can then make either the 2 -devel pakcages conflict, or put the symlink in a 
> subdir of /usr/lib[64] and have a pkg-config file (which are usually versioned) 
> and use pkg-config to add the correct -L/..... path to the LD_FLAGS.
> 
> This (symlinks in subdirs of /usr/lib, pkg-config) is how many libraries which 
> are designed for parallel installs do it. In the case of lm_sensors the plan 
> for Feodra is to switch to libsensors4 and just patch all users to move to the 
> new API, I much rather spend some time writing patches for libsensors using 
> apps, then spend time to make the 2 parallel installable. Also notice that as 
> the 2 are inherently not paralell installable as the both want to install 
> /usr/include/sensors/sensors.h

I'm interested in this because in openSuse, there's currently no
separate devel package for sensors. I plan to make one before moving to
3.0.0, so I need to learn how this is supposed to work.

I also don't plan to make both devel packages installable in parallel,
it's not worth the effort.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hans,
> 
> On Sun, 21 Oct 2007 21:13:35 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> How do you deal with the case where both libsensors.so.3 and
>>> libsensors.so.4 are available at link time?
>> Well -lsensors will search for libsensors.so, which is a symlink to one of the 
>> two, I would expect this symlink to point to the same version as 
>> /usr/include/sensors/sensors.h is.
> 
> Ah, OK. I didn't realize this before, thanks for the clarification.
> 
> I somehow expected / hoped that it was possible to explicitly point ld
> to a specific .so version, but apparently this isn't the case.
> 
>> When talking distros, the symlinks usually reside in the -devel package. One 
>> can then make either the 2 -devel pakcages conflict, or put the symlink in a 
>> subdir of /usr/lib[64] and have a pkg-config file (which are usually versioned) 
>> and use pkg-config to add the correct -L/..... path to the LD_FLAGS.
>>
>> This (symlinks in subdirs of /usr/lib, pkg-config) is how many libraries which 
>> are designed for parallel installs do it. In the case of lm_sensors the plan 
>> for Feodra is to switch to libsensors4 and just patch all users to move to the 
>> new API, I much rather spend some time writing patches for libsensors using 
>> apps, then spend time to make the 2 parallel installable. Also notice that as 
>> the 2 are inherently not paralell installable as the both want to install 
>> /usr/include/sensors/sensors.h
> 
> I'm interested in this because in openSuse, there's currently no
> separate devel package for sensors. I plan to make one before moving to
> 3.0.0, so I need to learn how this is supposed to work.
> 

In general, anything not needed runtime goes in the -devel package, so thats 
the .so symlink, static (.a) versions of the lib (if you want to have one at 
all, Fedora has done away with static libs), headers, developer documentation 
like section 3 manpages, and README's / FAQ's / whatever more geared towards 
developers then users. You may also want to build sensorsd and put it in a 
seperate sub-package.

Also you will need to create a package for the now seperated i2c tools. I still 
need todo this too, you may use mine as a base once its there.

Regards,

Hans


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Mon, 22 Oct 2007 09:06:27 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > I'm interested in this because in openSuse, there's currently no
> > separate devel package for sensors. I plan to make one before moving to
> > 3.0.0, so I need to learn how this is supposed to work.
> 
> In general, anything not needed runtime goes in the -devel package, so thats 
> the .so symlink, static (.a) versions of the lib (if you want to have one at 
> all, Fedora has done away with static libs), headers, developer documentation 
> like section 3 manpages, and README's / FAQ's / whatever more geared towards 
> developers then users.

OK.

>                        You may also want to build sensorsd and put it in a 
> seperate sub-package.

That's my plan, yes. We do provide sensord but not in a separate
sub-package at the moment. Given that most users do not use sensord, I
don't think it makes sense to include it by default.

> Also you will need to create a package for the now seperated i2c tools. I still 
> need todo this too, you may use mine as a base once its there.

This is done already, I started with this right after releasing
i2c-tools 3.0.0.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
>> Also you will need to create a package for the now seperated i2c tools. I still 
>> need todo this too, you may use mine as a base once its there.
> 
> This is done already, I started with this right after releasing
> i2c-tools 3.0.0.
> 

Good, could you send me the .spec file, please? Then I have something to start 
with for Fedora.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Mon, 22 Oct 2007 10:13:27 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> >> Also you will need to create a package for the now seperated i2c tools. I still 
> >> need todo this too, you may use mine as a base once its there.
> > 
> > This is done already, I started with this right after releasing
> > i2c-tools 3.0.0.
> 
> Good, could you send me the .spec file, please? Then I have something to start 
> with for Fedora.

Will do (in private.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
>>> I expected applications to deal with the
>>> different versions on their own. But if you think that a #define in
>>> sensors.h would help, just go ahead, that's fine with me.
>> Well as explained above ./configure and the Makefiles don't need to know about 
>> the different versions, So only some code changes are needed, for which it 
>> would be nice if a #define is present to test for.
> 
> As I said, just go ahead and add the #define you want. Feel free to add
> the "same" #define to trunk if it helps.
> 

Done,

I've also added a comment how to use it in future versions. The idea is to 
increment the lower digit when for example new features are added to the 
featuretype enum, so that applications can check the SENSORS_API_VERSION and 
conditionally support new features for example (if they don't/can't check they 
will no longer compile against an older libsensors).

The middle digit is both an overflow for the lower, and/or for bigger changes 
like the addition of methods. I know the addition of methods would mean apps 
compiled against the new version will not work with the old, but this is quite 
normal todo, see for example gtk2 and many others.

Let me know what you think of this scheme and / or feel free to change it.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Mon, 22 Oct 2007 11:40:11 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> >>> I expected applications to deal with the
> >>> different versions on their own. But if you think that a #define in
> >>> sensors.h would help, just go ahead, that's fine with me.
> >> Well as explained above ./configure and the Makefiles don't need to know about 
> >> the different versions, So only some code changes are needed, for which it 
> >> would be nice if a #define is present to test for.
> > 
> > As I said, just go ahead and add the #define you want. Feel free to add
> > the "same" #define to trunk if it helps.
> 
> Done,
> 
> I've also added a comment how to use it in future versions. The idea is to 
> increment the lower digit when for example new features are added to the 
> featuretype enum, so that applications can check the SENSORS_API_VERSION and 
> conditionally support new features for example (if they don't/can't check they 
> will no longer compile against an older libsensors).

I think I wouldn't have bothered. If applications no longer compile
with an older libsensors, then just upgrade libsensors.

> The middle digit is both an overflow for the lower, and/or for bigger changes 
> like the addition of methods. I know the addition of methods would mean apps 
> compiled against the new version will not work with the old, but this is quite 
> normal todo, see for example gtk2 and many others.

Yes, that's not a problem.

> Let me know what you think of this scheme and / or feel free to change it.

If someone is willing to maintain the API number, that's fine with me.
Me, I'll try to remember, but as I know myself, chances are good that
I'll forget sometimes if nobody is watching over me.

Just one thing I'm curious about: are you sure you want to set the API
to 400 _decimal_? Setting it to 0x400 instead seems to be more
flexible, as is allows for constructs like:

#if (SENSORS_API_VERSION >> 16) = 4

which is plain impossible to do with a decimal version number. I agree
that you can always replace the above with direct value comparisons,
but I guess that some more flexibility cannot hurt.

Another thing: don't you want to define SENSORS_API_VERSION in trunk as
well? If not, you'll always have to test for SENSORS_API_VERSION's
existence before checking its value. I know that versions up to and
including 2.10.4 do not have the define and we can't change that, but
maybe applications will want to support all versions >= 2.10.5 so that
the #if magic can be limited to something sane.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Mon, 22 Oct 2007 11:40:11 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>>>> I expected applications to deal with the
>>>>> different versions on their own. But if you think that a #define in
>>>>> sensors.h would help, just go ahead, that's fine with me.
>>>> Well as explained above ./configure and the Makefiles don't need to know about 
>>>> the different versions, So only some code changes are needed, for which it 
>>>> would be nice if a #define is present to test for.
>>> As I said, just go ahead and add the #define you want. Feel free to add
>>> the "same" #define to trunk if it helps.
>> Done,
>>
>> I've also added a comment how to use it in future versions. The idea is to 
>> increment the lower digit when for example new features are added to the 
>> featuretype enum, so that applications can check the SENSORS_API_VERSION and 
>> conditionally support new features for example (if they don't/can't check they 
>> will no longer compile against an older libsensors).
> 
> I think I wouldn't have bothered. If applications no longer compile
> with an older libsensors, then just upgrade libsensors.
> 

That would mean much pain for distro developers which want to minimize churn, 
but may still need to upgrade an application because of security reasons.

>> The middle digit is both an overflow for the lower, and/or for bigger changes 
>> like the addition of methods. I know the addition of methods would mean apps 
>> compiled against the new version will not work with the old, but this is quite 
>> normal todo, see for example gtk2 and many others.
> 
> Yes, that's not a problem.
> 
>> Let me know what you think of this scheme and / or feel free to change it.
> 
> If someone is willing to maintain the API number, that's fine with me.
> Me, I'll try to remember, but as I know myself, chances are good that
> I'll forget sometimes if nobody is watching over me.
> 

I'll try to keep an eye on it. I hope that if we forget users will complain.

> Just one thing I'm curious about: are you sure you want to set the API
> to 400 _decimal_? Setting it to 0x400 instead seems to be more
> flexible, as is allows for constructs like:
> 
> #if (SENSORS_API_VERSION >> 16) = 4
> 
 > which is plain impossible to do with a decimal version number.

Well with mine one can do:
#if (SENSORS_API_VERSION / 100) = 4

But I'm fine with either.

> Another thing: don't you want to define SENSORS_API_VERSION in trunk as
> well? If not, you'll always have to test for SENSORS_API_VERSION's
> existence before checking its value. I know that versions up to and
> including 2.10.4 do not have the define and we can't change that, but
> maybe applications will want to support all versions >= 2.10.5 so that
> the #if magic can be limited to something sane.
> 

Not necessary, if an identifier which is not a MACRO gets used in an #if 
statement it is considered zero, so to take you example:
#if (SENSORS_API_VERSION / 100) = 4

Would expand to:
#if (0 / 100) = 4

And thus be false.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

On Mon, 22 Oct 2007 15:15:51 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Mon, 22 Oct 2007 11:40:11 +0200, Hans de Goede wrote:
> >> I've also added a comment how to use it in future versions. The idea is to 
> >> increment the lower digit when for example new features are added to the 
> >> featuretype enum, so that applications can check the SENSORS_API_VERSION and 
> >> conditionally support new features for example (if they don't/can't check they 
> >> will no longer compile against an older libsensors).
> > 
> > I think I wouldn't have bothered. If applications no longer compile
> > with an older libsensors, then just upgrade libsensors.
> 
> That would mean much pain for distro developers which want to minimize churn, 
> but may still need to upgrade an application because of security reasons.

My experience is that distributions backport fixes for security bugs,
rather than upgrading to the next version of the application or the
library. But I don't actually think this is the right way to do it, so
I'll buy your argument :)

> > If someone is willing to maintain the API number, that's fine with me.
> > Me, I'll try to remember, but as I know myself, chances are good that
> > I'll forget sometimes if nobody is watching over me.
> 
> I'll try to keep an eye on it. I hope that if we forget users will complain.

The problem with this kind of thing is that, by the time users
complain, it's too late: you have a released version with a broken
define and you can't change that. So let's just hope it won't happen.

> > Just one thing I'm curious about: are you sure you want to set the API
> > to 400 _decimal_? Setting it to 0x400 instead seems to be more
> > flexible, as is allows for constructs like:
> > 
> > #if (SENSORS_API_VERSION >> 16) = 4
> > 
> > which is plain impossible to do with a decimal version number.
> 
> Well with mine one can do:
> #if (SENSORS_API_VERSION / 100) = 4
> 
> But I'm fine with either.

Ah right, I tend to forget that >> is nothing more than a division ;)
But... still, I think I'd feel more confident if we used hexadecimal.

> > Another thing: don't you want to define SENSORS_API_VERSION in trunk as
> > well? If not, you'll always have to test for SENSORS_API_VERSION's
> > existence before checking its value. I know that versions up to and
> > including 2.10.4 do not have the define and we can't change that, but
> > maybe applications will want to support all versions >= 2.10.5 so that
> > the #if magic can be limited to something sane.
> 
> Not necessary, if an identifier which is not a MACRO gets used in an #if 
> statement it is considered zero, so to take you example:
> #if (SENSORS_API_VERSION / 100) = 4
> 
> Would expand to:
> #if (0 / 100) = 4
> 
> And thus be false.

Unless the application is built with -Wundef (which is our case now),
in which case a warning is issued. That's what I would like to avoid.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> On Mon, 22 Oct 2007 15:15:51 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> On Mon, 22 Oct 2007 11:40:11 +0200, Hans de Goede wrote:
>>>> I've also added a comment how to use it in future versions. The idea is to 
>>>> increment the lower digit when for example new features are added to the 
>>>> featuretype enum, so that applications can check the SENSORS_API_VERSION and 
>>>> conditionally support new features for example (if they don't/can't check they 
>>>> will no longer compile against an older libsensors).
>>> I think I wouldn't have bothered. If applications no longer compile
>>> with an older libsensors, then just upgrade libsensors.
>> That would mean much pain for distro developers which want to minimize churn, 
>> but may still need to upgrade an application because of security reasons.
> 
> My experience is that distributions backport fixes for security bugs,
> rather than upgrading to the next version of the application or the
> library. But I don't actually think this is the right way to do it, so
> I'll buy your argument :)
> 

Well Fedora as a fast moving distro usually upgrades rather then backports.

>> Well with mine one can do:
>> #if (SENSORS_API_VERSION / 100) = 4
>>
>> But I'm fine with either.
> 
> Ah right, I tend to forget that >> is nothing more than a division ;)
> But... still, I think I'd feel more confident if we used hexadecimal.
> 

Ok, changed to hexadecimal

>>> Another thing: don't you want to define SENSORS_API_VERSION in trunk as
>>> well? If not, you'll always have to test for SENSORS_API_VERSION's
>>> existence before checking its value. I know that versions up to and
>>> including 2.10.4 do not have the define and we can't change that, but
>>> maybe applications will want to support all versions >= 2.10.5 so that
>>> the #if magic can be limited to something sane.
>> Not necessary, if an identifier which is not a MACRO gets used in an #if 
>> statement it is considered zero, so to take you example:
>> #if (SENSORS_API_VERSION / 100) = 4
>>
>> Would expand to:
>> #if (0 / 100) = 4
>>
>> And thus be false.
> 
> Unless the application is built with -Wundef (which is our case now),
> in which case a warning is issued. That's what I would like to avoid.
> 

Ok, added to trunk, with an initial value of 0x300

Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Aurelien Jarno]

Jean Delvare a écrit :
Hi Jean,

>> However I have a remark to ease the transition from version 2.x.x to
>> version 3.0.0: it is currently possible to have the two libraries
>> installed, but they both use the same configuration file. What about
>> having different config files for the two versions (e.g. sensors.conf
>> and sensors3.conf) ?
> 
> Technically speaking, the libraries themselves don't have default
> configuration files. Applications do. That makes the matter only worse.

I agree that the library itself doesn't have any default. However, the
scripts in the source tarball install the configuration file as sensors.conf

> For openSuse, my plan was to get plain rid of lm-sensors 2 and all
> applications using it as soon as possible, so that no such conflict
> happens. I don't think we'll package libsensors v2.10.x in the next
> release. I don't know what Hans' plans are for Fedora. Of course, if
> you intend to guarantee backwards compatibility by shipping the old
> libsensors for a longer time in Debian, then indeed you have a problem.

I still don't know if we want to support backward compatibility in
Debian, but we have a lot more applications to port, so I don't know how
long it will take.

> The fact that applications, rather than the library, set the default
> configuration file name, means that it's essentially out of our control.
> We could change sensors and sensord in lm-sensors 3.0.0 to use a
> different default, but that won't solve the problem for all the 3rd
> party applications out there. You'd need to change them all. Either the
> authors do, or the packagers will have to.
> 
> If you want to use /etc/sensors3.conf as the default for applications
> using lm-sensors 3 in Debian, there's nothing preventing you from doing
> that. This doesn't really have to be done upstream. That being said, I
> agree that it would become confusing if different distributions come up
> with different naming schemes.

Yes I agree the code can be changed, and having a common policy for all
distributions is a good point for the users.

> Coming to think about it, I think it's silly to have the default
> configuration file name in applications. There's really no reason why
> an application would want to use a different default, is there? So it
> might be the right time to change this and put the default
> configuration file name in libsensors. Calling sensors_init(NULL) would
> use that default. It would make it easier to change the default if a
> distribution wants to, and it would enforce a common default for
> applications using the new library. Opinions?

Looks like a really good idea, I vote for it.

> I don't much like the idea of using /etc/sensors3.conf for lm-sensors
> 3. Soon enough, lm-sensors 2 will be history, sensors.conf will no
> longer exist, and we'll be stuck with /etc/sensors3.conf. That's a bit
> unaesthetic, isn't it? A slightly different approach would be to
> use /etc/sensors3.conf if it exists, and /etc/sensors.conf otherwise
> (as was done for the XFree86 configuration file from version 3.x to
> version 4.x; remember?) This approach preserves compatibility with
> existing installations and offers a nice upgrade path. But of course
> this can only be (easily) implemented if the default is handled in
> libsensors rather than in the applications themselves, as I proposed
> above.

I think it is a good option. In case it is chosen, I advise to explain
that in the doc, otherwise the users may be confused.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Jean Delvare]

Hi Hans,

On Mon, 22 Oct 2007 21:27:29 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Mon, 22 Oct 2007 15:15:51 +0200, Hans de Goede wrote:
> >> Well with mine one can do:
> >> #if (SENSORS_API_VERSION / 100) = 4
> >>
> >> But I'm fine with either.
> > 
> > Ah right, I tend to forget that >> is nothing more than a division ;)
> > But... still, I think I'd feel more confident if we used hexadecimal.
> 
> Ok, changed to hexadecimal

OK, thanks. Additionally, don't you think you should document it in
libsensors.3? I guess that this is what application authors are
reading, rather than sensors.h itself.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Mon, 22 Oct 2007 21:27:29 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> On Mon, 22 Oct 2007 15:15:51 +0200, Hans de Goede wrote:
>>>> Well with mine one can do:
>>>> #if (SENSORS_API_VERSION / 100) = 4
>>>>
>>>> But I'm fine with either.
>>> Ah right, I tend to forget that >> is nothing more than a division ;)
>>> But... still, I think I'd feel more confident if we used hexadecimal.
>> Ok, changed to hexadecimal
> 
> OK, thanks. Additionally, don't you think you should document it in
> libsensors.3? I guess that this is what application authors are
> reading, rather than sensors.h itself.
> 

I understand your pov, but I would rather not, it is better to have no 
documentation then to have incomplete / out of date documentation IMHO. I think 
it is best not to document this unless we also plan on keeping an complete list 
of which API additions where done between bumps of the value.

Also I don't know if I'm a typical userspace programmer, but I often look in 
header files, esp. when looking for things like library version defines.

Last but not least a programmer will already need to look at the sensors.h file 
for the meaning / possible values of sensors_subfeature_type for example.

Regards,

Hans


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors