* [lm-sensors] Need some input for cleaning up FSC userspace code
@ 2007-10-11 14:54 Hans de Goede
2007-10-11 18:29 ` Hans de Goede
2007-10-12 14:56 ` Jean Delvare
0 siblings, 2 replies; 3+ messages in thread
From: Hans de Goede @ 2007-10-11 14:54 UTC (permalink / raw)
To: lm-sensors
Hi all,
I've been working today on creating support for the new fschmd in the 2.10.x
tree for the 2.10.5 release.
I've added code like this too the current fscpos (and fscher and fscscy) print
code:
void print_fscpos(const sensors_chip_name *name)
{
char *label;
double voltage, temp, state, fan;
int valid;
/* Check for the non standard temp1_state sysfs attr the old driver uses
if it isn't present we are talking to the new fschmd driver */
if (sensors_get_feature(*name,SENSORS_FSCPOS_TEMP1_STATE,&state) != 0) {
print_fschmd(name);
return;
}
/* no need to read TEMP1_STATE, as we just successfully did that above */
if (!sensors_get_label_and_valid(*name,SENSORS_FSCPOS_TEMP1,&label,&valid) &&
!sensors_get_feature(*name,SENSORS_FSCPOS_TEMP1,&temp)) {
......
This works fine with the old driver, however it won't work with the new driver
as currently lib/chips.c still contains the features list for the old driver,
which btw is not in a good state:
[hans@localhost lm-sensors]$ /usr/local/bin/sensors -u
fscher-i2c-0-73
Adapter: SMBus I801 adapter at 2400
ERROR: Can't get feature `rev' data!
alarms: 0.00 (alarms)
control: 0.00 (control)
+12V: 1.89 (in0)
+5V: 1.98 (in1)
Battery: 2.45 (in2)
Temp1/CPU: 39.00 (temp1)
temp1_state: 1.00 (temp1_state)
Temp2/MB: 34.00 (temp2)
temp2_state: 1.00 (temp2_state)
Temp3/AUX: 127.00 (temp3)
temp3_state: 0.00 (temp3_state)
Fan1/PS: 1320.00 (fan1)
pwm1: 1.00 (pwm1)
fan1_state: 0.00 (fan1_state)
ERROR: Can't get feature `fan1_ripple' data!
Fan2/CPU: 0.00 (fan2)
pwm2: 1.00 (pwm2)
fan2_state: 0.00 (fan2_state)
ERROR: Can't get feature `fan2_ripple' data!
Fan3/AUX: 0.00 (fan3)
pwm3: 1.00 (pwm3)
fan3_state: 0.00 (fan3_state)
ERROR: Can't get feature `fan3_ripple' data!
ERROR: Can't get feature `wdog_preset' data!
ERROR: Can't get feature `wdog_state' data!
ERROR: Can't get feature `wdog_control' data!
As you can see it refers to several 2.4 features not present or renamed in the
2.6 driver.
So what I want todo is add features for the old driver non sysfs interface
compliant attributes which are used in the old print_fscpos code, like
temp#_state and fan#_state, to the fschmd features list, and then use that
features list for all fsc chip prefixes. Then I'll update the old print code
for the old fscpos, scy and her drivers to use the new feature numbers and
things will work.
However this will break any existing applications which depend on the old FSC
SCY / POS / HER feature numbers. We have no in tree users of these, but still.
So what todo?
I guess it would be best to:
-use my suggested fix to make one fschmd feature list including needed old
features and use that everywhere, but ....
-make the feature numbers so that they are compatible with the feature numbers
of the old attributes
But then what todo with the no longer existing features, avoid the numbers in
the new fschmd feature list I guess, or still put them in for 2.4 users?
I guess I need to think a bit more about this, in the mean time any input is
appreciated.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [lm-sensors] Need some input for cleaning up FSC userspace code
2007-10-11 14:54 [lm-sensors] Need some input for cleaning up FSC userspace code Hans de Goede
@ 2007-10-11 18:29 ` Hans de Goede
2007-10-12 14:56 ` Jean Delvare
1 sibling, 0 replies; 3+ messages in thread
From: Hans de Goede @ 2007-10-11 18:29 UTC (permalink / raw)
To: lm-sensors
Hi all,
Please ignore my rambling. While cycling home from work I gave this some more
thought and I think I know how to solve this while keeping full compatibility
with the current libsensors and apps using it.
Regards,
Hans
Hans de Goede wrote:
> Hi all,
>
> I've been working today on creating support for the new fschmd in the 2.10.x
> tree for the 2.10.5 release.
>
> I've added code like this too the current fscpos (and fscher and fscscy) print
> code:
>
> void print_fscpos(const sensors_chip_name *name)
> {
> char *label;
> double voltage, temp, state, fan;
> int valid;
>
> /* Check for the non standard temp1_state sysfs attr the old driver uses
> if it isn't present we are talking to the new fschmd driver */
> if (sensors_get_feature(*name,SENSORS_FSCPOS_TEMP1_STATE,&state) != 0) {
> print_fschmd(name);
> return;
> }
>
> /* no need to read TEMP1_STATE, as we just successfully did that above */
> if (!sensors_get_label_and_valid(*name,SENSORS_FSCPOS_TEMP1,&label,&valid) &&
> !sensors_get_feature(*name,SENSORS_FSCPOS_TEMP1,&temp)) {
> ......
>
>
>
> This works fine with the old driver, however it won't work with the new driver
> as currently lib/chips.c still contains the features list for the old driver,
> which btw is not in a good state:
>
> [hans@localhost lm-sensors]$ /usr/local/bin/sensors -u
> fscher-i2c-0-73
> Adapter: SMBus I801 adapter at 2400
> ERROR: Can't get feature `rev' data!
> alarms: 0.00 (alarms)
> control: 0.00 (control)
> +12V: 1.89 (in0)
> +5V: 1.98 (in1)
> Battery: 2.45 (in2)
> Temp1/CPU: 39.00 (temp1)
> temp1_state: 1.00 (temp1_state)
> Temp2/MB: 34.00 (temp2)
> temp2_state: 1.00 (temp2_state)
> Temp3/AUX: 127.00 (temp3)
> temp3_state: 0.00 (temp3_state)
> Fan1/PS: 1320.00 (fan1)
> pwm1: 1.00 (pwm1)
> fan1_state: 0.00 (fan1_state)
> ERROR: Can't get feature `fan1_ripple' data!
> Fan2/CPU: 0.00 (fan2)
> pwm2: 1.00 (pwm2)
> fan2_state: 0.00 (fan2_state)
> ERROR: Can't get feature `fan2_ripple' data!
> Fan3/AUX: 0.00 (fan3)
> pwm3: 1.00 (pwm3)
> fan3_state: 0.00 (fan3_state)
> ERROR: Can't get feature `fan3_ripple' data!
> ERROR: Can't get feature `wdog_preset' data!
> ERROR: Can't get feature `wdog_state' data!
> ERROR: Can't get feature `wdog_control' data!
>
> As you can see it refers to several 2.4 features not present or renamed in the
> 2.6 driver.
>
>
> So what I want todo is add features for the old driver non sysfs interface
> compliant attributes which are used in the old print_fscpos code, like
> temp#_state and fan#_state, to the fschmd features list, and then use that
> features list for all fsc chip prefixes. Then I'll update the old print code
> for the old fscpos, scy and her drivers to use the new feature numbers and
> things will work.
>
> However this will break any existing applications which depend on the old FSC
> SCY / POS / HER feature numbers. We have no in tree users of these, but still.
>
> So what todo?
>
> I guess it would be best to:
> -use my suggested fix to make one fschmd feature list including needed old
> features and use that everywhere, but ....
> -make the feature numbers so that they are compatible with the feature numbers
> of the old attributes
>
> But then what todo with the no longer existing features, avoid the numbers in
> the new fschmd feature list I guess, or still put them in for 2.4 users?
>
> I guess I need to think a bit more about this, in the mean time any input is
> appreciated.
>
> Regards,
>
> Hans
>
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [lm-sensors] Need some input for cleaning up FSC userspace code
2007-10-11 14:54 [lm-sensors] Need some input for cleaning up FSC userspace code Hans de Goede
2007-10-11 18:29 ` Hans de Goede
@ 2007-10-12 14:56 ` Jean Delvare
1 sibling, 0 replies; 3+ messages in thread
From: Jean Delvare @ 2007-10-12 14:56 UTC (permalink / raw)
To: lm-sensors
On Thu, 11 Oct 2007 20:29:14 +0200, Hans de Goede wrote:
> Please ignore my rambling. While cycling home from work I gave this some more
> thought and I think I know how to solve this while keeping full compatibility
> with the current libsensors and apps using it.
... which is why bike is so much better than car for daily
transportation ;)
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-10-12 14:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-11 14:54 [lm-sensors] Need some input for cleaning up FSC userspace code Hans de Goede
2007-10-11 18:29 ` Hans de Goede
2007-10-12 14:56 ` Jean Delvare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.