Re: [lm-sensors] xsensors ported to the future libsensors

[Hans de Goede <j.w.r.degoede@hhs.nl>]

Jean Delvare wrote:
> Hi Hans,
> 
> On Fri, 20 Jul 2007 22:33:17 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> I just finished porting xsensors to the version of libsensors we have
>>> in branch lm-sensors-3.0.0. I wanted to have a second application using
>>> it at hand, because I don't think that sensors is representative of the
>>> rest of the libsensors users: it's one-shot nature make it different.
>>> As I want to improve the API, having more than one application will
>>> make it less likely that I overlook an important need.
>>>
>>> You can download the patch from here:
>>> http://jdelvare.pck.nerim.net/sensors/xsensors-libsensors4.patch
>>> I'll keep it up-to-date as the libsensors API evolves.
>>>
>>> Note: I don't know how to force an application to link with
>>> libsensors.so.4 rather than libsensors.so.3, so you'll have to make
>>> sure that libsensors.so.4 is found first when building xsensors.
>> Good work! Gnome sensors-applet or the gkrellm libsensors code might also be 
>> interesting, as those both already use libsensors as a generic chip abstraction 
>> layer, iow they do not contain any chip specific code, like xsensors it seems 
>> used to.
> 
> The chip-specific code in xsensors is really only to tell which feature
> numbers need to be used for each chip. It really could have been data
> tables rather than code. That left apart, xsensors has a greater level
> of abstraction than even the new libsensors. For example it describes
> the subfeatures "relatively" to the main feature, independent of its
> type (e.g. tempX_max and inX_max are handled the same way.) Compare
> this to "sensors" which has specific code for each sensor type. This
> might be something to consider for libsensors (SENSORS_FEATURE_TEMP_MAX
> = SENSORS_FEATURE_IN_MAX)... or not, I'm not sure yet.
> 
> I'm curious how gnome sensors-applet and gkrellm managed to use the
> current libsensors without chip-specific code at all, as it definitely
> wasn't designed to be used that way.

They both basically have there own version of sensors_get_feature_type, both 
assuming to be running on a 2.6 kernel, and thus have sysfs interface standard 
feature names.

Converting them thus should be easy. (I wrote the gkrellm libsensors code 
myself, so I will probably also be the one converting it).

Regards,

Hans


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