[lm-sensors] Misc API changes for libsensors4

[lm-sensors] Misc API changes for libsensors4

[Jean Delvare]

Hi all,

As libsensors4 won't be compatible with libsensors3 (thus the major
version number change) it's the right time for small adjustments to the
API, which we won't be allowed to do later. After reviewing the current
API, I have the following proposals, and I would like to know if there
are objections to me doing these changes.

* Drop support for reloading the configuration from sensors_init().
Instead, the application will have to call sensors_exit() explicitly
before calling sensors_init() again. Rationale: most applications don't
offer any way to reload the configuration file, so better optimize for
the initial load.

* Change the prototype of sensors_get_label() from
	int sensors_get_label(const sensors_chip_name *name, int feature, char **result)
to
	char *sensors_get_label(const sensors_chip_name *name, int feature)

Errors can be reported with a NULL pointer.

* Rename sensors_get_feature() and sensors_set_feature() to
sensors_get_value() and sensors_set_value(), respectively. Rationale:
the new names better reflect what the functions do.

* Change the prototype of sensors_get_detected_chips from
	const sensors_chip_name *sensors_get_detected_chips(int *nr)
to
	const sensors_chip_name *sensors_get_detected_chips(const sensors_chip_name *name, int *nr)

The application would pass a chip name possibly containing wildcards,
so sensors_get_detected_chips() could check for matches itself (using
sensors_match_chip). Passing an all-wildcard chip name (or NULL?) would
restore the old behavior. This makes it easier to let the user chose a
subset of chips to print (as can be done with sensors' command line) by
moving the code into the library. We may then be able to make
sensors_match_chip private, as this is the last use in sensors and
sensord.

* Drop SENSORS_MODE_NO_RW and SENSORS_MODE_RW. The mode is a bitfield,
we typically set, or test for, a specific bit. As a matter of fact,
these two symbols aren't used anywhere in libsensors, sensors, sensord,
ksensors nor xsensors.

If anyone has objections or comments, please let me know.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Misc API changes for libsensors4

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> As libsensors4 won't be compatible with libsensors3 (thus the major
> version number change) it's the right time for small adjustments to the
> API, which we won't be allowed to do later. After reviewing the current
> API, I have the following proposals, and I would like to know if there
> are objections to me doing these changes.
> 
> * Drop support for reloading the configuration from sensors_init().
> Instead, the application will have to call sensors_exit() explicitly
> before calling sensors_init() again. Rationale: most applications don't
> offer any way to reload the configuration file, so better optimize for
> the initial load.
> 
> * Change the prototype of sensors_get_label() from
> 	int sensors_get_label(const sensors_chip_name *name, int feature, char **result)
> to
> 	char *sensors_get_label(const sensors_chip_name *name, int feature)
> 
> Errors can be reported with a NULL pointer.
> 
> * Rename sensors_get_feature() and sensors_set_feature() to
> sensors_get_value() and sensors_set_value(), respectively. Rationale:
> the new names better reflect what the functions do.
> 
> * Change the prototype of sensors_get_detected_chips from
> 	const sensors_chip_name *sensors_get_detected_chips(int *nr)
> to
> 	const sensors_chip_name *sensors_get_detected_chips(const sensors_chip_name *name, int *nr)
> 
> The application would pass a chip name possibly containing wildcards,
> so sensors_get_detected_chips() could check for matches itself (using
> sensors_match_chip). Passing an all-wildcard chip name (or NULL?) would
> restore the old behavior. This makes it easier to let the user chose a
> subset of chips to print (as can be done with sensors' command line) by
> moving the code into the library. We may then be able to make
> sensors_match_chip private, as this is the last use in sensors and
> sensord.
> 
> * Drop SENSORS_MODE_NO_RW and SENSORS_MODE_RW. The mode is a bitfield,
> we typically set, or test for, a specific bit. As a matter of fact,
> these two symbols aren't used anywhere in libsensors, sensors, sensord,
> ksensors nor xsensors.
> 
> If anyone has objections or comments, please let me know.
> 

All suggested changes sound fine to me.

Regards,

Hans


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

Re: [lm-sensors] Misc API changes for libsensors4

[Ivo Manca]

Hey Jean,

As we saw with my struggle for supporting the PCChips motherboard with 
the sis5595 chip, we had a problem with a voltage channel which was 
connected to a temperature sensors. However, there was no way to let 
sensors know that the in4 was actually temperature instead of voltage. 
I've added the related mail below (14/06/2007). Is this something for 
libsensors4?

Ivo


----- Original Message ----- 
From: "Jean Delvare" <khali@linux-fr.org>
To: "Hans de Goede" <j.w.r.degoede@hhs.nl>
Cc: "Ivo Manca" <pinkel@gmail.com>; <lm-sensors@lm-sensors.org>
Sent: Thursday 14 June 2007 21:13
Subject: Re: [lm-sensors] sis5595


> Hans,
>
> On Tue, 12 Jun 2007 19:42:29 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>> > If you can't get additional information, you can label in4 "CPU 
>> > Temp",
>> > observe the reading over a period of time, and set arbitrary limits
>> > accordingly. Unfortunately we have no way to tell "sensors" that a
>> > voltage input is actually a temperature value.
>>
>> Is it possible other motherboards manufacturers have done something 
>> similar?
>
> Well, it is possible to do this with virtually any voltage input of 
> all
> driver. But maybe this is more likely for the in4 of the sis5595
> because it can already be used for temperature monitoring (although in
> a technically different way.)
>
>> Ifso would it be an idea to add a driver flag to rename all the in4 
>> sysfs attr
>> to tempX sysfs attr, without changing the way how things are read?
>
> Yes, this could be done, shouldn't be too expensive.
>
> A more generic solution would be to implement this in libsensors. For
> that we'd need a new sensors.conf directive to change the type of a
> given sensor (from voltage to temp in this case). After all, the only
> difference is the unit displayed after the value. There are a few
> driver which could use this: pc87360, vt8231... which currently export
> voltage value as temp* files for thermistor-based measurements.
>
> -- 
> Jean Delvare



----- Original Message ----- 
From: "Jean Delvare" <khali@linux-fr.org>
To: "LM Sensors" <lm-sensors@lm-sensors.org>
Sent: Friday 17 August 2007 22:54
Subject: [lm-sensors] Misc API changes for libsensors4


> Hi all,
>
> As libsensors4 won't be compatible with libsensors3 (thus the major
> version number change) it's the right time for small adjustments to 
> the
> API, which we won't be allowed to do later. After reviewing the 
> current
> API, I have the following proposals, and I would like to know if there
> are objections to me doing these changes.
>
> * Drop support for reloading the configuration from sensors_init().
> Instead, the application will have to call sensors_exit() explicitly
> before calling sensors_init() again. Rationale: most applications 
> don't
> offer any way to reload the configuration file, so better optimize for
> the initial load.
>
> * Change the prototype of sensors_get_label() from
> int sensors_get_label(const sensors_chip_name *name, int feature, char 
> **result)
> to
> char *sensors_get_label(const sensors_chip_name *name, int feature)
>
> Errors can be reported with a NULL pointer.
>
> * Rename sensors_get_feature() and sensors_set_feature() to
> sensors_get_value() and sensors_set_value(), respectively. Rationale:
> the new names better reflect what the functions do.
>
> * Change the prototype of sensors_get_detected_chips from
> const sensors_chip_name *sensors_get_detected_chips(int *nr)
> to
> const sensors_chip_name *sensors_get_detected_chips(const 
> sensors_chip_name *name, int *nr)
>
> The application would pass a chip name possibly containing wildcards,
> so sensors_get_detected_chips() could check for matches itself (using
> sensors_match_chip). Passing an all-wildcard chip name (or NULL?) 
> would
> restore the old behavior. This makes it easier to let the user chose a
> subset of chips to print (as can be done with sensors' command line) 
> by
> moving the code into the library. We may then be able to make
> sensors_match_chip private, as this is the last use in sensors and
> sensord.
>
> * Drop SENSORS_MODE_NO_RW and SENSORS_MODE_RW. The mode is a bitfield,
> we typically set, or test for, a specific bit. As a matter of fact,
> these two symbols aren't used anywhere in libsensors, sensors, 
> sensord,
> ksensors nor xsensors.
>
> If anyone has objections or comments, please let me know.
>
> Thanks,
> -- 
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors 


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

Re: [lm-sensors] Misc API changes for libsensors4

[Jean Delvare]

Hi Ivo,

On Tue, 21 Aug 2007 11:40:52 +0200, Ivo Manca wrote:
> As we saw with my struggle for supporting the PCChips motherboard with 
> the sis5595 chip, we had a problem with a voltage channel which was 
> connected to a temperature sensors. However, there was no way to let 
> sensors know that the in4 was actually temperature instead of voltage. 
> I've added the related mail below (14/06/2007). Is this something for 
> libsensors4?

Good point. I seem to remember that we had excluded the possibility to
handle this at the driver level, as virtually every chip can be wired
that way and we didn't want to modify all the drivers. And I can't think
of an easy way to centralize it in a single kernel module either.

To handle it in libsensors, the only missing part as far as I can see
is a way to change the channel type, so that "sensors" displays the
right things using the right units. We already have the value conversion
support in place (using compute statements) so this part is OK.

Channel types could be changed with a new statement in sensors.conf, say
"type in4 temp" or something similar. Then feature types would be
changed on the fly, just like we drop features with "ignore" statements.

Changing channel types would probably be easier if we were using the
same numbers for all channel type subfeatures, which isn't currently
the case. I seem to remember that we were discussing this with Hans a
few weeks ago. Back then I had no strong argument to change it, but
this may be a good one. I'll look into this later.

One thing that might cause problem is that the limits may need to be
swapped depending on the thermistor type. I see no easy way to detect
this though [1]. This is somewhat similar to some of the negative
voltages, and although people sometimes ask about this, we seem to be
able to live with it (with a FAQ entry maybe.)

It would be great if you could create a trac ticket to track this
feature request, so that it doesn't get overlooked.

Thanks.

[1] Well I do see a way, we could analyze the compute statement to find
out in which direction the result changes depending on the raw value
variations. Still I'm not sure if it's worth the effort.

-- 
Jean Delvare

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