[lm-sensors] xsensors ported to the future libsensors

[lm-sensors] xsensors ported to the future libsensors

[Jean Delvare]

Hi all,

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.

-- 
Jean Delvare

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

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

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> 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.

Regards,

Hans


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

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

[Jean Delvare]

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. But anyway this will be
interesting to see how they can be converted to the new libsensors.
I'll leave it to someone else though. For one thing, I'll be busy
enough with xsensors and later sensord. For another, letting others
comment on the new API will be very valuable.

Thanks,
-- 
Jean Delvare

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

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

[Hans de Goede]

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

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

[Jean Delvare]

On Sun, 22 Jul 2007 20:06:02 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > 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.

I'm surprised, as the feature names exposed by libsensors are the old
(non-standard) ones, even for 2.6 kernels. The mapping to the new
symbols is internal as far as I can see. "sensors -u" returns the old
feature names. So I guess they assume that old names are somewhat
standard, and it doesn't work for all drivers?

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

Great, thanks.

-- 
Jean Delvare

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

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

[Hans de Goede]

Jean Delvare wrote:
> On Sun, 22 Jul 2007 20:06:02 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> 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.
> 
> I'm surprised, as the feature names exposed by libsensors are the old
> (non-standard) ones, even for 2.6 kernels. The mapping to the new
> symbols is internal as far as I can see. "sensors -u" returns the old
> feature names. So I guess they assume that old names are somewhat
> standard, and it doesn't work for all drivers?
> 

Correct, but gkrellm does for example contain code to also work with the 
via686a 2.0V style volt feature names

Regards,

Hans

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