Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

jk wrote:
> I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
> 
> I now notice that the sensors location varies between
> /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
> between reboots.
> 
> This creates problems for me since I use sensord and a crontab entry to read the
> sensors but now the location of the sensors in /sys varies with each boot.
> 
> Is this a bug?
> If not is there a way to fix the location of the sensor directory in the /sys
> heirarch? (Otherwise, I will need to write some klugey shell script to try to
> find the location at boot-up and then automatically change the crontab entry
> accordingly.
> 
> Thanks!
> 

Interesting, I've been thinking about this for while, as I foresee problems 
here in relation to the DMI based motherboard config project we are working on too.

I think that the currently used scheme where busses are purely numbered instead 
of named needs fixing.

Here is what I have on my system:
/sys/bus/i2c/devices/0-0050
/sys/bus/i2c/devices/0-0051

And here is what I would like to have:
/sys/bus/i2c/devices/viapro-0-0050
/sys/bus/i2c/devices/viapro-0-0051

The idea here is that the 0 added here is in case one can have multiple 
instances of the same i2c master driver

So if I would also have an i2c driver for my ati radeon, then it would look like:
/sys/bus/i2c/devices/viapro-0-0050
/sys/bus/i2c/devices/viapro-0-0051
/sys/bus/i2c/devices/radeon-0-00xx

This way the order in which the drivers get loaded doesn't matter. We do 
ofcourse need to provide compat symlinks with the old names which will still be 
driver loading order dependend.

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[jk]

>jk wrote:
>> I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
>> 
>> I now notice that the sensors location varies between
>> /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
>> between reboots.
>> 
>> This creates problems for me since I use sensord and a crontab entry to read the
>> sensors but now the location of the sensors in /sys varies with each boot.
>> 
>> Is this a bug?
>> If not is there a way to fix the location of the sensor directory in the /sys
>> heirarch? (Otherwise, I will need to write some klugey shell script to try to
>> find the location at boot-up and then automatically change the crontab entry
>> accordingly.
>> 
>> Thanks!
>> 
>
>Interesting, I've been thinking about this for while, as I foresee problems 
>here in relation to the DMI based motherboard config project we are working on too.
>
>I think that the currently used scheme where busses are purely numbered instead 
>of named needs fixing.
>
>Here is what I have on my system:
>/sys/bus/i2c/devices/0-0050
>/sys/bus/i2c/devices/0-0051
>
>And here is what I would like to have:
>/sys/bus/i2c/devices/viapro-0-0050
>/sys/bus/i2c/devices/viapro-0-0051
>
>The idea here is that the 0 added here is in case one can have multiple 
>instances of the same i2c master driver
>
>So if I would also have an i2c driver for my ati radeon, then it would look like:
>/sys/bus/i2c/devices/viapro-0-0050
>/sys/bus/i2c/devices/viapro-0-0051
>/sys/bus/i2c/devices/radeon-0-00xx
>
>This way the order in which the drivers get loaded doesn't matter. We do 
>ofcourse need to provide compat symlinks with the old names which will still be 
>driver loading order dependend.
>
>Regards,
>
>Hans

Agreed.

Note that I also seem to have an 'extra' layer in that my devices sit
in an asb100 subdirectory (see below) whereas yours seem to sit right
in the /sys/i2c/bus/devices directory. So I guess that mine already
has some 'naming' built in.


I guess my *practical* questions in the meantime until naming gets
changed are the following:

1. Why does the device number prefix change from '0' to '2' on
   different boots? Also, why does the sensor jump to 2-002d when
   there is NO 0-002d or 1-002d sensor? i.e. I would have thought you
   would only get 2-002d if there were already a (conflicting) 0-002d
   or 1-002d sensor.

   Note I believe I have only one asb100 sensor (corresponding to my
   p4pe motherboard) but maybe the numbering gets mixed in with other
   i2c devices (I have a nVIdia GeForce Ti 4600 graphic board, a
   Winfast 2000XP Deluxe analog TV card, and a pcHDTV 5500 digital TV
   card).

2. Why did none of this happen in the 2.4 kernels where I just used
   as99127f-i2c-0-2d all the time?

3. What if anything can I do to 'fix' the sensor to a specific prefix?
   (Perhaps something analogous to what one does in modprobe.conf with
   the index=n option or maybe something to force the boot order to be
   consistent)


For reference, my (current) /sys/i2c/bus/devices tree looks like this:
./asb100
./asb100/0-0048
./asb100/0-0049
./asb100/0-002d
./asb100/bind
./asb100/unbind
./asb100/module
./eeprom
./eeprom/2-0050
./eeprom/0-0052
./eeprom/0-0051
./eeprom/0-0050
./eeprom/bind
./eeprom/unbind
./eeprom/module
./tuner
./tuner/1-0061
./tuner/bind
./tuner/unbind
./tuner/module
./tveeprom
./tveeprom/1-0050
./tveeprom/bind
./tveeprom/unbind
./tveeprom/module
./i2c_adapter
./i2c_adapter/bind
./i2c_adapter/unbind
./i2c_adapter/module

Of course, the sensor I am interested in reading here is: asb100/0-002d

Thanks


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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

jk wrote:
>> jk wrote:
>>> I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
>>>
>>> I now notice that the sensors location varies between
>>> /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
>>> between reboots.
>>>
>>> This creates problems for me since I use sensord and a crontab entry to read the
>>> sensors but now the location of the sensors in /sys varies with each boot.
>>>
>>> Is this a bug?
>>> If not is there a way to fix the location of the sensor directory in the /sys
>>> heirarch? (Otherwise, I will need to write some klugey shell script to try to
>>> find the location at boot-up and then automatically change the crontab entry
>>> accordingly.
>>>
>>> Thanks!
>>>
>> Interesting, I've been thinking about this for while, as I foresee problems 
>> here in relation to the DMI based motherboard config project we are working on too.
>>
>> I think that the currently used scheme where busses are purely numbered instead 
>> of named needs fixing.
>>
>> Here is what I have on my system:
>> /sys/bus/i2c/devices/0-0050
>> /sys/bus/i2c/devices/0-0051
>>
>> And here is what I would like to have:
>> /sys/bus/i2c/devices/viapro-0-0050
>> /sys/bus/i2c/devices/viapro-0-0051
>>
>> The idea here is that the 0 added here is in case one can have multiple 
>> instances of the same i2c master driver
>>
>> So if I would also have an i2c driver for my ati radeon, then it would look like:
>> /sys/bus/i2c/devices/viapro-0-0050
>> /sys/bus/i2c/devices/viapro-0-0051
>> /sys/bus/i2c/devices/radeon-0-00xx
>>
>> This way the order in which the drivers get loaded doesn't matter. We do 
>> ofcourse need to provide compat symlinks with the old names which will still be 
>> driver loading order dependend.
>>
>> Regards,
>>
>> Hans
> 
> Agreed.
> 
> Note that I also seem to have an 'extra' layer in that my devices sit
> in an asb100 subdirectory (see below) whereas yours seem to sit right
> in the /sys/i2c/bus/devices directory. So I guess that mine already
> has some 'naming' built in.
> 
> 
> I guess my *practical* questions in the meantime until naming gets
> changed are the following:
> 
> 1. Why does the device number prefix change from '0' to '2' on
>    different boots? Also, why does the sensor jump to 2-002d when
>    there is NO 0-002d or 1-002d sensor? i.e. I would have thought you
>    would only get 2-002d if there were already a (conflicting) 0-002d
>    or 1-002d sensor.
> 

The first number is the i2c bus, the second the address on the bus.

>    Note I believe I have only one asb100 sensor (corresponding to my
>    p4pe motherboard) but maybe the numbering gets mixed in with other
>    i2c devices (I have a nVIdia GeForce Ti 4600 graphic board, a
>    Winfast 2000XP Deluxe analog TV card, and a pcHDTV 5500 digital TV
>    card).
> 
> 2. Why did none of this happen in the 2.4 kernels where I just used
>    as99127f-i2c-0-2d all the time?
> 

Because modules where loaded there by initscripts / through /etc/modules.conf 
and that tended to happen in a fixed order. Now adays when udev registers 
itself as hotplug handler the kernel starts firing hotplug events for al 
already detected hardware and the drivers get loaded in parrallel, so there is 
no fixed order in the loading of the i2c bus masters, and thus no fixed 
addresses for the asb, as the address consists of busnumber-busaddress


> 3. What if anything can I do to 'fix' the sensor to a specific prefix?
>    (Perhaps something analogous to what one does in modprobe.conf with
>    the index=n option or maybe something to force the boot order to be
>    consistent)
> 

You could try to disable / blacklist non used i2c masters, but you have atleast 
the smbus controller on your board and one for your tvcard which you both need, 
another hack would be to modprobe the smbus driver from your rc.sysinit script 
  before udev gets started.

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[jk]

Hans de Goede wrote at about 18:21:10 +0200 on Friday, April 6, 2007:
 > jk wrote:
 > >> jk wrote:
 > >>> I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
 > >>>
 > >>> I now notice that the sensors location varies between
 > >>> /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
 > >>> between reboots.
 > >>>
 > >>> This creates problems for me since I use sensord and a crontab entry to read the
 > >>> sensors but now the location of the sensors in /sys varies with each boot.
 > >>>
 > >>> Is this a bug?
 > >>> If not is there a way to fix the location of the sensor directory in the /sys
 > >>> heirarch? (Otherwise, I will need to write some klugey shell script to try to
 > >>> find the location at boot-up and then automatically change the crontab entry
 > >>> accordingly.
 > >>>
 > >>> Thanks!
 > >>>
 > > 
 > > Agreed.
 > > 
 > > Note that I also seem to have an 'extra' layer in that my devices sit
 > > in an asb100 subdirectory (see below) whereas yours seem to sit right
 > > in the /sys/i2c/bus/devices directory. So I guess that mine already
 > > has some 'naming' built in.
 > > 
 > > 
 > > I guess my *practical* questions in the meantime until naming gets
 > > changed are the following:
 > > 
 > > 1. Why does the device number prefix change from '0' to '2' on
 > >    different boots? Also, why does the sensor jump to 2-002d when
 > >    there is NO 0-002d or 1-002d sensor? i.e. I would have thought you
 > >    would only get 2-002d if there were already a (conflicting) 0-002d
 > >    or 1-002d sensor.
 > > 
 > 
 > The first number is the i2c bus, the second the address on the bus.

Just to make sure I understand, it then seems that in my current
config, I have the following:
        i2c bus #0 (p4pe motherboard): 
                asb100 (0-002d)
                asb100 subclient (0-0048)
                asb100 subclient (0-0049)
                eeprom (0-0050)
                eeprom (0-0051)
                eeprom (0-0052)
        i2c bus #1: (Winfast 2000XP Deluxe card)
                tveeprom (1-0050)
                tuner (1-0061)
        i2c bus #1: (pcHDTV-5500??)
                eeprom (2-0050)

 > >    Note I believe I have only one asb100 sensor (corresponding to my
 > >    p4pe motherboard) but maybe the numbering gets mixed in with other
 > >    i2c devices (I have a nVIdia GeForce Ti 4600 graphic board, a
 > >    Winfast 2000XP Deluxe analog TV card, and a pcHDTV 5500 digital TV
 > >    card).
 > > 
 > > 2. Why did none of this happen in the 2.4 kernels where I just used
 > >    as99127f-i2c-0-2d all the time?
 > > 
 > 
 > Because modules where loaded there by initscripts / through /etc/modules.conf 
 > and that tended to happen in a fixed order. Now adays when udev registers 
 > itself as hotplug handler the kernel starts firing hotplug events for al 
 > already detected hardware and the drivers get loaded in parrallel, so there is 
 > no fixed order in the loading of the i2c bus masters, and thus no fixed 
 > addresses for the asb, as the address consists of busnumber-busaddress

I am then surprised that many more people are not having this
problem. It would seem then that this "race condition" would apply to
anybody who had more than one i2c bus.
Perhaps though there are not many people who are using sensord/rrd
though... (however, if you are and set up the crontab as recommended
then you will get cron email errors mailed to you every 5 minutes :)

 > > 3. What if anything can I do to 'fix' the sensor to a specific prefix?
 > >    (Perhaps something analogous to what one does in modprobe.conf with
 > >    the index=n option or maybe something to force the boot order to be
 > >    consistent)
 > > 
 > 
 > You could try to disable / blacklist non used i2c masters, but you have atleast 
 > the smbus controller on your board and one for your tvcard which you both need, 
 > another hack would be to modprobe the smbus driver from your rc.sysinit script 
 >   before udev gets started.
 > 
 > Regards,
 > 
 > Hans

I believe that I need all 3 i2c masters.
For the rc.sysinit hack, I assume you mean just insert a statement of
form:
        modprobe asb100

Is that right?

I still though can't believe that there is not a better/more
controlled way to make this work.


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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[jk]

Perhaps there is another way of looking at.
How does the program 'sensors' know what <busnumber>-<busaddress>
combination to use?

Maybe this could be used to rewrite the script sens_update_rrd to
automatically find and read the right sensor data?

Alternatively, maybe sens_update_rrd should be rewritten to call
'sensors' and parse the resulting output rather than querying directly
the /sys/bus/i2c/devices/<busnumber>-<busaddress> sensor values?

Or maybe I should just be using sensord instead which would avoid
having to specify the sensor or to edit the /etc/crontab file?
(however, I like the other cgi scripts better)

I guess in summary it seems to me that the primary problem is that the
crontab script sens_update_rrd is written in a non-robust fashion...



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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

jk wrote:
> Hans de Goede wrote at about 18:21:10 +0200 on Friday, April 6, 2007:
>  > jk wrote:
>  > >> jk wrote:
>  > >>> I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
>  > >>>
>  > >>> I now notice that the sensors location varies between
>  > >>> /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
>  > >>> between reboots.
>  > >>>
>  > >>> This creates problems for me since I use sensord and a crontab entry to read the
>  > >>> sensors but now the location of the sensors in /sys varies with each boot.
>  > >>>
>  > >>> Is this a bug?
>  > >>> If not is there a way to fix the location of the sensor directory in the /sys
>  > >>> heirarch? (Otherwise, I will need to write some klugey shell script to try to
>  > >>> find the location at boot-up and then automatically change the crontab entry
>  > >>> accordingly.
>  > >>>
>  > >>> Thanks!
>  > >>>
>  > > 
>  > > Agreed.
>  > > 
>  > > Note that I also seem to have an 'extra' layer in that my devices sit
>  > > in an asb100 subdirectory (see below) whereas yours seem to sit right
>  > > in the /sys/i2c/bus/devices directory. So I guess that mine already
>  > > has some 'naming' built in.
>  > > 
>  > > 
>  > > I guess my *practical* questions in the meantime until naming gets
>  > > changed are the following:
>  > > 
>  > > 1. Why does the device number prefix change from '0' to '2' on
>  > >    different boots? Also, why does the sensor jump to 2-002d when
>  > >    there is NO 0-002d or 1-002d sensor? i.e. I would have thought you
>  > >    would only get 2-002d if there were already a (conflicting) 0-002d
>  > >    or 1-002d sensor.
>  > > 
>  > 
>  > The first number is the i2c bus, the second the address on the bus.
> 
> Just to make sure I understand, it then seems that in my current
> config, I have the following:
>         i2c bus #0 (p4pe motherboard): 
>                 asb100 (0-002d)
>                 asb100 subclient (0-0048)
>                 asb100 subclient (0-0049)
>                 eeprom (0-0050)
>                 eeprom (0-0051)
>                 eeprom (0-0052)
>         i2c bus #1: (Winfast 2000XP Deluxe card)
>                 tveeprom (1-0050)
>                 tuner (1-0061)
>         i2c bus #1: (pcHDTV-5500??)
>                 eeprom (2-0050)
> 
>  > >    Note I believe I have only one asb100 sensor (corresponding to my
>  > >    p4pe motherboard) but maybe the numbering gets mixed in with other
>  > >    i2c devices (I have a nVIdia GeForce Ti 4600 graphic board, a
>  > >    Winfast 2000XP Deluxe analog TV card, and a pcHDTV 5500 digital TV
>  > >    card).
>  > > 
>  > > 2. Why did none of this happen in the 2.4 kernels where I just used
>  > >    as99127f-i2c-0-2d all the time?
>  > > 
>  > 
>  > Because modules where loaded there by initscripts / through /etc/modules.conf 
>  > and that tended to happen in a fixed order. Now adays when udev registers 
>  > itself as hotplug handler the kernel starts firing hotplug events for al 
>  > already detected hardware and the drivers get loaded in parrallel, so there is 
>  > no fixed order in the loading of the i2c bus masters, and thus no fixed 
>  > addresses for the asb, as the address consists of busnumber-busaddress
> 
> I am then surprised that many more people are not having this
> problem. It would seem then that this "race condition" would apply to
> anybody who had more than one i2c bus.
> Perhaps though there are not many people who are using sensord/rrd
> though... (however, if you are and set up the crontab as recommended
> then you will get cron email errors mailed to you every 5 minutes :)
> 
>  > > 3. What if anything can I do to 'fix' the sensor to a specific prefix?
>  > >    (Perhaps something analogous to what one does in modprobe.conf with
>  > >    the index=n option or maybe something to force the boot order to be
>  > >    consistent)
>  > > 
>  > 
>  > You could try to disable / blacklist non used i2c masters, but you have atleast 
>  > the smbus controller on your board and one for your tvcard which you both need, 
>  > another hack would be to modprobe the smbus driver from your rc.sysinit script 
>  >   before udev gets started.
>  > 
>  > Regards,
>  > 
>  > Hans
> 
> I believe that I need all 3 i2c masters.
> For the rc.sysinit hack, I assume you mean just insert a statement of
> form:
>         modprobe asb100
> 
> Is that right?
> 

About right, but you need to modprobe the driver for your smbus controller / 
the i2c master on your motherboard, as that is the one jumping from 0 - 2, the 
asb100 is always at 2d

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

jk wrote:
> Perhaps there is another way of looking at.
> How does the program 'sensors' know what <busnumber>-<busaddress>
> combination to use?
> 

It doesn't the asb100 address is "configured" with this line in 
/etc/sensors.conf: 'chip "asb100-*"'

The * being the address, iow sensors will show any asb100 independent of the 
address.

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Hans,

On Fri, 06 Apr 2007 09:19:48 +0200, Hans de Goede wrote:
> jk wrote:
> > I have a p4pe board with the asb_100 sensor running under linux 2.6.20.
> > 
> > I now notice that the sensors location varies between
> > /sys/bus/i2c/drivers/asb100/0-002d and /sys/bus/i2c/drivers/asb100/2-002d
> > between reboots.
> > 
> > This creates problems for me since I use sensord and a crontab entry to read the
> > sensors but now the location of the sensors in /sys varies with each boot.
> > 
> > Is this a bug?
> > If not is there a way to fix the location of the sensor directory in the /sys
> > heirarch? (Otherwise, I will need to write some klugey shell script to try to
> > find the location at boot-up and then automatically change the crontab entry
> > accordingly.
> 
> Interesting, I've been thinking about this for while, as I foresee problems 
> here in relation to the DMI based motherboard config project we are working on too.
> 
> I think that the currently used scheme where busses are purely numbered instead 
> of named needs fixing.
> 
> Here is what I have on my system:
> /sys/bus/i2c/devices/0-0050
> /sys/bus/i2c/devices/0-0051
> 
> And here is what I would like to have:
> /sys/bus/i2c/devices/viapro-0-0050
> /sys/bus/i2c/devices/viapro-0-0051
> 
> The idea here is that the 0 added here is in case one can have multiple 
> instances of the same i2c master driver

Which directly points to a weakness in your proposal: if you have two
adapters of the same type, they'll get named foo-0 and foo-1. How do
you know which is which? You don't, so you only moved the problem one
step further, you didn't solve it.

My understanding is that this is a problem for user-space to solve, it
should not assume stable device numbering accross reboots. But it used
to be the case and many user-space tools still rely on this.

> So if I would also have an i2c driver for my ati radeon, then it would look like:
> /sys/bus/i2c/devices/viapro-0-0050
> /sys/bus/i2c/devices/viapro-0-0051
> /sys/bus/i2c/devices/radeon-0-00xx
> 
> This way the order in which the drivers get loaded doesn't matter. We do 
> ofcourse need to provide compat symlinks with the old names which will still be 
> driver loading order dependend.

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

On 06 Apr 2007 13:21:59 -0400, jk wrote:
> I am then surprised that many more people are not having this
> problem. It would seem then that this "race condition" would apply to
> anybody who had more than one i2c bus.

Let me guess, your kernel is compiled with
CONFIG_PCI_MULTITHREAD_PROBE=y?

> Perhaps though there are not many people who are using sensord/rrd
> though... (however, if you are and set up the crontab as recommended
> then you will get cron email errors mailed to you every 5 minutes :)

First of all, the right way to look for hardware monitoring devices
on a reasonably recent Linux 2.6 kernel is through /sys/class/hwmon.
Historically, tools have been assuming that hardware monitoring devices
were always presented as I2C devices and looked for them
in /sys/bus/i2c/devices, but this is no longer correct. Granted though,
libsensors still identifies i2c devices using their i2c device names
internally. Maybe we'll need to change that someday. That being said,
it moves the problem more than it solves it, when more than one
hardware monitoring device is present on a system (which becomes more
frequent these days.)

Secondly, libsensors supports consistent i2c bus numbering for years,
for specific-device configuration sections. See the "BUS STATEMENT"
section in sensors.conf(5).

This doesn't cover all cases, but these are things to keep in mind when
facing device naming issues.

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

Jean Delvare wrote:
> Secondly, libsensors supports consistent i2c bus numbering for years,
> for specific-device configuration sections. See the "BUS STATEMENT"
> section in sensors.conf(5).
> 

He, cool thats just about what I suggested in my last mail in this thread, 
somehow I feel a clue bat / rtfm remark coming my way :)

/me ducks

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Fri, 06 Apr 2007 09:19:48 +0200, Hans de Goede wrote:
>> Here is what I have on my system:
>> /sys/bus/i2c/devices/0-0050
>> /sys/bus/i2c/devices/0-0051
>>
>> And here is what I would like to have:
>> /sys/bus/i2c/devices/viapro-0-0050
>> /sys/bus/i2c/devices/viapro-0-0051
>>
>> The idea here is that the 0 added here is in case one can have multiple 
>> instances of the same i2c master driver
> 
> Which directly points to a weakness in your proposal: if you have two
> adapters of the same type, they'll get named foo-0 and foo-1. How do
> you know which is which? You don't, so you only moved the problem one
> step further, you didn't solve it.
> 

I agree, but still I think there is some worth in my proposal. For one it makes 
the problem smaller, for example in case of the poster of the asb_100 problem, 
it will make the problem go away.

Also say I have a system with multiple identical masters, for example 2 nvidea 
cards in SDI. Last time I looked at the device model code (2 years ago) when 
you would register a new driver, the bus code would do a linear pass along all 
the devices on the bus (and sub-busses) and see if the driver matched a device, 
device by device, then upon a match the bus code will call the driver_detect 
method, and once that has returned, it will go look at the next device on the 
bus, etc. Thus AFAIK assuming for example PCI masters, foo-0 and foo-1 will 
always get enumerated in fixed order.

> My understanding is that this is a problem for user-space to solve, it
> should not assume stable device numbering accross reboots. But it used
> to be the case and many user-space tools still rely on this.
> 

After writing my initial mail about this, I've done some more thinking about 
this and I agree, this should be solved at the userspace level.

So in our case in libsensors, thus I would like to propose to change the 
libsensors name format for i2c from chipname-i2c-busnumber-address to
chipname-i2cmastername-masternumber-address

So for example. the SPD eeprom at i2c address 50 of my via smbus master would 
be: "eeprom-i2c_viapro-0-50", Yes i know libsensors doesn't handle eeproms, 
this is just an example.

I have also been thinking about ways to give the masters even uniquer names 
then just numbering indentical masters, but anything I came up with was full of 
holes.

The whole idea behind this "exercise" is to be able to make the dmi autoloaded 
configs more explicit on which chip is located on which bus, and thus not 
loading any drivers on i2c busses where they might do harm.

Which brings me to the question, when insmodding an i2c-client driver, is it 
possible to tell it which masters to scan?

Regards,

Hans

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[lmsensors]

On 06 Apr 2007 13:21:59 -0400, jk wrote:
> > I am then surprised that many more people are not having this
> > problem. It would seem then that this "race condition" would apply to
> > anybody who had more than one i2c bus.
> 
> Let me guess, your kernel is compiled with
> CONFIG_PCI_MULTITHREAD_PROBE=y?
 
I don't know. I am using a standard Fedora Core 2.6.20 kernel and I
don't see that option name in the top level .config file. Should I be
looking elsewhere in the tree for that variable name?
 
> > Perhaps though there are not many people who are using sensord/rrd
> > though... (however, if you are and set up the crontab as recommended
> > then you will get cron email errors mailed to you every 5 minutes :)
> 
> First of all, the right way to look for hardware monitoring devices
> on a reasonably recent Linux 2.6 kernel is through /sys/class/hwmon.
> Historically, tools have been assuming that hardware monitoring devices
> were always presented as I2C devices and looked for them
> in /sys/bus/i2c/devices, but this is no longer correct. Granted though,
> libsensors still identifies i2c devices using their i2c device names
> internally. Maybe we'll need to change that someday. That being said,
> it moves the problem more than it solves it, when more than one
> hardware monitoring device is present on a system (which becomes more
> frequent these days.)

That is good to know about /sys/class/hwmon since that will presumably
solve my problems directly. 

I think though that part of the problem is that many of the user-space
programs and documentation in the lm_sensors tarball (at least in
version 2.10.1) are not updated for recent 2.6 kernels.

For example, the program sens_update_rrd looks in either
/proc/sys/dev/sensors (which is obsolete) or in /sys/bus/i2c/devices
(which gives the problems I have).

Instead it should just go to /sys/class/hwmon and be done with it!

Also, just as a random example, the documentation for sensors.conf
when discussing about the BUS STATEMENT (which I found by your reference
below) only talks about /proc/bus/i2c which is obsolete for 2.6
kernels. Similarly, it references the program
prog/config/grab_busses.sh which only works in 2.4 kernels.

So, I guess the better question is whether anybody plans on updating
the documentation and auxiliary programs in the lm_sensors tarball to
reflect 2.6 kernels in general and "later" 2.6 kernels in particular.

> Secondly, libsensors supports consistent i2c bus numbering for years,
> for specific-device configuration sections. See the "BUS STATEMENT"
> section in sensors.conf(5).
> 
> This doesn't cover all cases, but these are things to keep in mind when
> facing device naming issues.
> 
> -- 
> Jean Delvare
> 


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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Hans,

On Sun, 08 Apr 2007 20:49:41 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Fri, 06 Apr 2007 09:19:48 +0200, Hans de Goede wrote:
> >> Here is what I have on my system:
> >> /sys/bus/i2c/devices/0-0050
> >> /sys/bus/i2c/devices/0-0051
> >>
> >> And here is what I would like to have:
> >> /sys/bus/i2c/devices/viapro-0-0050
> >> /sys/bus/i2c/devices/viapro-0-0051
> >>
> >> The idea here is that the 0 added here is in case one can have multiple 
> >> instances of the same i2c master driver
> > 
> > Which directly points to a weakness in your proposal: if you have two
> > adapters of the same type, they'll get named foo-0 and foo-1. How do
> > you know which is which? You don't, so you only moved the problem one
> > step further, you didn't solve it.
> 
> I agree, but still I think there is some worth in my proposal. For one it makes 
> the problem smaller, for example in case of the poster of the asb_100 problem, 
> it will make the problem go away.

If we decide to change the sysfs naming scheme, this isn't a trivial
change, and we will have to keep the new scheme in place pretty much
forever. Thus making the problem smaller isn't nearly enough. If we
change something, the new scheme must address the problem as a whole,
and as permanently as we can imagine now.

> Also say I have a system with multiple identical masters, for example 2 nvidea 
> cards in SDI. Last time I looked at the device model code (2 years ago) when 
> you would register a new driver, the bus code would do a linear pass along all 
> the devices on the bus (and sub-busses) and see if the driver matched a device, 
> device by device, then upon a match the bus code will call the driver_detect 
> method, and once that has returned, it will go look at the next device on the 
> bus, etc. Thus AFAIK assuming for example PCI masters, foo-0 and foo-1 will 
> always get enumerated in fixed order.

You build the new names stability on the assumption that something else
will keep being stable (here, the order in which a given driver
registers multiple devices). This is exactly what was done before, and
the reason why you are proposing a change. The current device naming
was stable as long as drivers were loaded in a well-defined order,
which pretty much everyone assumed, 5 years ago, would forever be the
case.

If we can't find a naming scheme which is absolutely stable, then I'd
rather live with what we have, and handle the bus number changes in
user-space - where I believe it belongs anyway, and you seem to agree.

> > My understanding is that this is a problem for user-space to solve, it
> > should not assume stable device numbering accross reboots. But it used
> > to be the case and many user-space tools still rely on this.
> 
> After writing my initial mail about this, I've done some more thinking about 
> this and I agree, this should be solved at the userspace level.
> 
> So in our case in libsensors, thus I would like to propose to change the 
> libsensors name format for i2c from chipname-i2c-busnumber-address to
> chipname-i2cmastername-masternumber-address
> 
> So for example. the SPD eeprom at i2c address 50 of my via smbus master would 
> be: "eeprom-i2c_viapro-0-50", Yes i know libsensors doesn't handle eeproms, 
> this is just an example.
> 
> I have also been thinking about ways to give the masters even uniquer names 
> then just numbering indentical masters, but anything I came up with was full of 
> holes.
> 
> The whole idea behind this "exercise" is to be able to make the dmi autoloaded 
> configs more explicit on which chip is located on which bus, and thus not 
> loading any drivers on i2c busses where they might do harm.

You don't actually load a driver "on an i2c bus". You load a driver,
and something decides what devices the driver attaches to. Right now,
that "something" is the hardware monitoring drivers themselves. It
might change in the future, though.

> Which brings me to the question, when insmodding an i2c-client driver, is it 
> possible to tell it which masters to scan?

If the driver uses one of the I2C_CLIENT_INSMOD* macros, yes, you have
fine-grained control over which busses and addresses are scanned. Try
"modinfo lm90" for an example. Additionally, in the case of hardware
monitoring drivers, I2C busses also need to have the I2C_CLASS_HWMON
flag set, otherwise they cannot be probed (not even if forced with a
module parameter, and that's a bug.)

The problem, however, is that these module parameters take I2C bus
numbers. So if the numbers change (and they will certainly change from
one system to the next) the parameters must be altered accordingly.
That's not portable.

Thanks to David Brownell's recent patchset, it should be possible to
replace these module parameters with something else, probably control
files in sysfs. I need some time to write a prototype though, this
probably won't happen before 3 weeks from now. And after that, it'll
take even longer before the drivers are converted to use the new way.

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

On 08 Apr 2007 16:17:31 -0400, lmsensors@kosowsky.org wrote:
> On 06 Apr 2007 13:21:59 -0400, jk wrote:
> > > I am then surprised that many more people are not having this
> > > problem. It would seem then that this "race condition" would apply to
> > > anybody who had more than one i2c bus.
> > 
> > Let me guess, your kernel is compiled with
> > CONFIG_PCI_MULTITHREAD_PROBE=y?
>  
> I don't know. I am using a standard Fedora Core 2.6.20 kernel and I
> don't see that option name in the top level .config file. Should I be
> looking elsewhere in the tree for that variable name?

No, .config is the right place to look at. I'm asking because this is
the only option I know of which may cause a given kernel to number i2c
busses differently across reboots. If not that, maybe the Fedora Core
init scripts are doing something unexpected, in which case we can't
help.

> > First of all, the right way to look for hardware monitoring devices
> > on a reasonably recent Linux 2.6 kernel is through /sys/class/hwmon.
> > Historically, tools have been assuming that hardware monitoring devices
> > were always presented as I2C devices and looked for them
> > in /sys/bus/i2c/devices, but this is no longer correct. Granted though,
> > libsensors still identifies i2c devices using their i2c device names
> > internally. Maybe we'll need to change that someday. That being said,
> > it moves the problem more than it solves it, when more than one
> > hardware monitoring device is present on a system (which becomes more
> > frequent these days.)
> 
> That is good to know about /sys/class/hwmon since that will presumably
> solve my problems directly. 
> 
> I think though that part of the problem is that many of the user-space
> programs and documentation in the lm_sensors tarball (at least in
> version 2.10.1) are not updated for recent 2.6 kernels.

True. Their number is hopefully shrinking, but there may be a couple
scripts still not ported.

> For example, the program sens_update_rrd looks in either
> /proc/sys/dev/sensors (which is obsolete) or in /sys/bus/i2c/devices
> (which gives the problems I have).

/proc/sys/dev/sensors isn't really obsolete, it is the right place to
look at for 2.4 kernels.

sens_update_rrd is not maintained as far as I know so I am not
surprised if you have some problems with it.

> Instead it should just go to /sys/class/hwmon and be done with it!

No, doing so would break compatility with older kernels. The right
thing to do is to look in /sys/class/hwmon first and fallback to old
places if that didn't work. This is what libsensors does.

> Also, just as a random example, the documentation for sensors.conf
> when discussing about the BUS STATEMENT (which I found by your reference
> below) only talks about /proc/bus/i2c which is obsolete for 2.6
> kernels. Similarly, it references the program
> prog/config/grab_busses.sh which only works in 2.4 kernels.
> 
> So, I guess the better question is whether anybody plans on updating
> the documentation and auxiliary programs in the lm_sensors tarball to
> reflect 2.6 kernels in general and "later" 2.6 kernels in particular.

What about you? Maybe you could stop complaining and actually help the
project?

I don't use sens_update_rrd myself, nor prog/config/grab_busses.sh, nor
bus statements. You do. Why would you expect me or anyone else to fix
them?

> > Secondly, libsensors supports consistent i2c bus numbering for years,
> > for specific-device configuration sections. See the "BUS STATEMENT"
> > section in sensors.conf(5).
> > 
> > This doesn't cover all cases, but these are things to keep in mind when
> > facing device naming issues.

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Jeff,

On Sun, 15 Apr 2007 07:48:42 +0000 (UTC), jk wrote:
> Jean Delvare <khali <at> linux-fr.org> writes:
> > On 08 Apr 2007 16:17:31 -0400, lmsensors <at> kosowsky.org wrote:
> > > Also, just as a random example, the documentation for sensors.conf
> > > when discussing about the BUS STATEMENT (which I found by your reference
> > > below) only talks about /proc/bus/i2c which is obsolete for 2.6
> > > kernels. Similarly, it references the program
> > > prog/config/grab_busses.sh which only works in 2.4 kernels.
> > > 
> > > So, I guess the better question is whether anybody plans on updating
> > > the documentation and auxiliary programs in the lm_sensors tarball to
> > > reflect 2.6 kernels in general and "later" 2.6 kernels in particular.
> > 
> > What about you? Maybe you could stop complaining and actually help the
> > project?
> 
> I believe I have been "asking questions" rather than "complaining". Usually,
> packages have existing maintainers and it would be a bit presumptuous of me as a
> newbie to lm_sensors to start rewriting base code without making sure first that
> I really understand the issue and the reason for the existing situation (which
> you and others have now just explained to me) and second that no one else is
> currently maintaining the code (which indeed it seems that no one else is doing).
> 
> And in fact, I have now adjusted the code to first check for existence of hwmon
> (and I also wrote another cleaner version that only looks at hwmon but I
> understand why you may not want that so as to preserve backwards compatibility.)

Actually, we've branched SVN development now and we have a branch which
will only support recent 2.6 kernels. So if you send this other patch
to us, we could apply it to that branch. Please check your e-mail client
settings first though, as the patch below was corrupted (tabs replaced
by spaces, trailing space deleted), I had to fix it by hand in order to
apply it.

> Anyway, here is the diff for the version that preserves backwards compatibility. 
> 
> --- sens_update_rrd             2007-04-08 01:18:16.000000000 -0400
> +++ sens_update_rrd.new         2007-04-15 03:42:15.000000000 -0400
> @@ -30,6 +30,7 @@
>  then
>         echo "usage: $0 database.rrd sensor"
>         echo "       sensor example: w83781d-isa-0290 (2.4) or 0-0290 (2.6)"
> +       echo "           or hwmon0 (later 2.6)"
>         exit 1
>  fi
>  #
> @@ -38,19 +39,23 @@
> 
>  SENSDIR=/proc/sys/dev/sensors
>  SDIR=/sys/bus/i2c/devices
> -if [ ! -d $SENSDIR ]
> +HWMONDIR=/sys/class/hwmon
> +SENSDEV=$2
> +if [ -d $HWMONDIR ]
>  then
> -       if [ ! -d $SDIR ]
> +       SYSFS=1
> +       SENSDIR=$HWMONDIR
> +       SENSDEV=$SENSDEV/device
> +elif [ -d $SDIR ]
>         then
> -               echo $0: 'No sensors found! (modprobe sensor modules?)'
> -               exit 1
> -       else
>                 SYSFS=1
>                 SENSDIR=$SDIR
> -       fi
> +elif [ ! -d $SENSDIR]
> +then
> +       echo $0: 'No sensors found! (modprobe sensor modules?)'
> +       exit 1
>  fi
> 
> -SENSDEV=$2
>  SENS=$SENSDIR/$SENSDEV
>  if [ ! -r $SENS ]
>  then

Applied, thanks! I fixed the indentation, and also reworded the first
error message so that it's clearer which kernel needs what syntax
exactly.

> > I don't use sens_update_rrd myself, nor prog/config/grab_busses.sh, nor
> > bus statements. You do. Why would you expect me or anyone else to fix
> > them?
> 
> Did I ever say I expected you to? But it is not an unreasonable expectation for
> there to be a maintainer of code or barring that some indication that the code
> is no longer supported. Also, I would think that even if the rrd stuff is seldom
> used that the documentation for a basic config file like sensors.conf should be
> up to date and should not just reference obsolete kernel 2.4 methods which by
> now are four years out of date.
> 
> In any case, I am happy to help where I can, but I don't appreciate being
> accused of complaining or of having unreasonable expectations that I never
> myself expressed or implied.

Sorry, it seems I've been a bit rude with you while you didn't deserve
it. I must have had a bad day or something. Please accept my apologies.

You mentioned that sensors.conf.5 was out-of-date, can you please send
a patch for it too?

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jeffrey J. Kosowsky]

Jean Delvare wrote at about 11:19:15 +0200 on Tuesday, April 17, 2007:
 > Hi Jeff,
 > 
 > On Sun, 15 Apr 2007 07:48:42 +0000 (UTC), jk wrote:
 > > Jean Delvare <khali <at> linux-fr.org> writes:
 > > > On 08 Apr 2007 16:17:31 -0400, lmsensors <at> kosowsky.org wrote:
 
 > > And in fact, I have now adjusted the code to first check for existence of hwmon
 > > (and I also wrote another cleaner version that only looks at hwmon but I
 > > understand why you may not want that so as to preserve backwards compatibility.)
 > 
 > Actually, we've branched SVN development now and we have a branch which
 > will only support recent 2.6 kernels. So if you send this other patch
 > to us, we could apply it to that branch. Please check your e-mail client
 > settings first though, as the patch below was corrupted (tabs replaced
 > by spaces, trailing space deleted), I had to fix it by hand in order to
 > apply it.

Actually, I think the problem was due to the fact that I posted via
gmane and somehow my cut-paste from a putty xterm on my Linux machine
to a Firefox html text box on my Windoze machine messed up the
tabs. So, I am mailing this directly from my Linux machine.

Here is the trimmed/streamlined version for 2.6 only:
[Note I also made the sensor an optional input parameter that defaults
to hwmon0 since that seems to be the most likely case for most users]

--- sens_update_rrd	2007-04-17 09:03:08.000000000 -0400
+++ sens_update_rrd.new	2007-04-17 09:16:26.000000000 -0400
@@ -2,9 +2,9 @@
 #    sens_update_rrd -
 #	Update a sensors rrd database.
 #	Sample usage:
-#		sens_update_rrd /var/lib/database.rrd w83781d-isa-0290
+#		sens_update_rrd /var/lib/database.rrd hwmon0
 #	Sample cron entry:
-#		*/5 * * * * /usr/local/bin/sens_update_rrd /var/lib/sensors-rrd/sensors.rrd w83781d-isa-0290
+#		*/5 * * * * /usr/local/bin/sens_update_rrd /var/lib/sensors-rrd/sensors.rrd hwmon0
 #
 #################################################################
 #
@@ -26,48 +26,35 @@
 #
 #################################################################
 #
-if [ $# -ne 2 ]
+if [ $# -lt 1 ]
 then
-	echo "usage: $0 database.rrd sensor"
-	echo "       sensor example: w83781d-isa-0290 (2.4) or 0-0290 (2.6)"
+	echo "usage: $0 database.rrd [hwmonN]"
 	exit 1
 fi
 #
 RRDPATH=/usr/bin
 RRDB=$1
 
-SENSDIR=/proc/sys/dev/sensors
-SDIR=/sys/bus/i2c/devices
-if [ ! -d $SENSDIR ]
-then
-	if [ ! -d $SDIR ]
-	then
-		echo $0: 'No sensors found! (modprobe sensor modules?)'
-		exit 1
-	else
-		SYSFS=1
-		SENSDIR=$SDIR
-	fi	
-fi
+SENSDIR=/sys/class/hwmon
+HWMON=hwmon0
+[ $2 ] && HWMON=$2
+SENS=$SENSDIR/$HWMON/device
 
-SENSDEV=$2
-SENS=$SENSDIR/$SENSDEV
-if [ ! -r $SENS ]
+if [ ! -d $SENS ]
 then
-	echo $0: 'No sensors found! (modprobe sensor modules?)'
+	echo "No sensors found in: $SENS"
+	echo "(modprobe sensor modules?)"
 	exit 1
 fi
 
 STRING=N
-if [ "$SYSFS" = "1" ]
-then
 	#
 	# Get the value from these sensor files (/sys)
 	#
 	SENSORS="fan1 fan2 fan3"
 	for i in $SENSORS
 	do
-		V="`cat $SENSDIR/$SENSDEV/${i}_input 2> /dev/null`"
+	V="`cat $SENS/${i}_input 2> /dev/null`"
 		if [ $? -ne 0 ]
 		then
 			STRING="${STRING}:U"
@@ -81,7 +68,7 @@
 	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
 	for i in $SENSORS
 	do
-		V="`cat $SENSDIR/$SENSDEV/${i}_input 2> /dev/null`"
+	V="`cat $SENS/${i}_input 2> /dev/null`"
 		if [ $? -ne 0 ]
 		then
 			STRING="${STRING}:U"
@@ -90,38 +77,6 @@
 			STRING="${STRING}:${V}"
 		fi
 	done
-else
-	#
-	# Get the second value from these sensor files (/proc)
-	#
-	SENSORS="fan1 fan2 fan3"
-	for i in $SENSORS
-	do
-		V="`cat $SENSDIR/$SENSDEV/$i 2> /dev/null`"
-		if [ $? -ne 0 ]
-		then
-			STRING="${STRING}:U"
-		else
-			V="`echo $V | cut -d ' ' -f 2`"
-			STRING="${STRING}:${V}"
-		fi
-	done
-	#
-	# Get the third value from these sensor files (/proc)
-	#
-	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
-	for i in $SENSORS
-	do
-		V="`cat $SENSDIR/$SENSDEV/$i 2> /dev/null`"
-		if [ $? -ne 0 ]
-		then
-			STRING="${STRING}:U"
-		else
-			V="`echo $V | cut -d ' ' -f 3`"
-			STRING="${STRING}:${V}"
-		fi
-	done
-fi
 
 #
 # Get the first value from these /proc files



 > > In any case, I am happy to help where I can, but I don't appreciate being
 > > accused of complaining or of having unreasonable expectations that I never
 > > myself expressed or implied.
 > 
 > Sorry, it seems I've been a bit rude with you while you didn't deserve
 > it. I must have had a bad day or something. Please accept my apologies.
 > 
No problem -- I appreciate all that you do for this project.

 > You mentioned that sensors.conf.5 was out-of-date, can you please send
 > a patch for it too?

I'm not sure how to fix some of this since I'm not really sure what
the 2.6 equivalent is, but here are the lines that need adjusting:

1.	The  second and third arguments are the description texts. They must
	be exactly match the texts as they appear  in  /proc/bus/i2c,
	except for trailing  spaces, which are removed both from the /proc entries
	and the arguments.

	[I don't know where you find the 'second and third argument'
	(which are the chip description) in 2.6 kernels]

2.	The  program  prog/config/grab_busses.sh in the source distribution
	can help you generate these lines.

	[This program needs to be fixed for Kernel 2.6 -- I don't use it
	so I don't know exactly what it does or how to fix it]


3.  The chip descriptions are equal to those appearing in
    /proc/sys/dev/sensors, but may contain the * wildcard.

	[Again, I don't know where you find the chip descriptions in 2.6
	kernels]

More generally, you may want to have someone who is more familiar with
the 'lm_sensors' project to review the full man page since it seems like
it hasn't been changed since Feb 1999.

Sorry, I couldn't be more helpful here...

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Jeff,

On Tue, 17 Apr 2007 09:34:38 -0400, Jeffrey J. Kosowsky wrote:
> Actually, I think the problem was due to the fact that I posted via
> gmane and somehow my cut-paste from a putty xterm on my Linux machine
> to a Firefox html text box on my Windoze machine messed up the
> tabs. So, I am mailing this directly from my Linux machine.

This patch is better, however I still failed to apply it to our SVN
repository (hunk #2 failed). Was it generated cleanly? Does it apply
cleanly to 2.10.3 on your side? Better send the patches as attachments
if inline isn't reliable.

> Here is the trimmed/streamlined version for 2.6 only:
> [Note I also made the sensor an optional input parameter that defaults
> to hwmon0 since that seems to be the most likely case for most users]

That's a good idea. That being said, systems with more than one
hardware monitoring device are becoming more popular.

> --- sens_update_rrd	2007-04-17 09:03:08.000000000 -0400
> +++ sens_update_rrd.new	2007-04-17 09:16:26.000000000 -0400
> @@ -2,9 +2,9 @@
>  #    sens_update_rrd -
>  #	Update a sensors rrd database.
>  #	Sample usage:
> -#		sens_update_rrd /var/lib/database.rrd w83781d-isa-0290
> +#		sens_update_rrd /var/lib/database.rrd hwmon0
>  #	Sample cron entry:
> -#		*/5 * * * * /usr/local/bin/sens_update_rrd /var/lib/sensors-rrd/sensors.rrd w83781d-isa-0290
> +#		*/5 * * * * /usr/local/bin/sens_update_rrd /var/lib/sensors-rrd/sensors.rrd hwmon0
>  #
>  #################################################################
>  #
> @@ -26,48 +26,35 @@
>  #
>  #################################################################
>  #
> -if [ $# -ne 2 ]
> +if [ $# -lt 1 ]

Maybe test -gt 2 too, for completeness?

>  then
> -	echo "usage: $0 database.rrd sensor"
> -	echo "       sensor example: w83781d-isa-0290 (2.4) or 0-0290 (2.6)"
> +	echo "usage: $0 database.rrd [hwmonN]"
>  	exit 1
>  fi
>  #
>  RRDPATH=/usr/bin
>  RRDB=$1
>  
> -SENSDIR=/proc/sys/dev/sensors
> -SDIR=/sys/bus/i2c/devices
> -if [ ! -d $SENSDIR ]
> -then
> -	if [ ! -d $SDIR ]
> -	then
> -		echo $0: 'No sensors found! (modprobe sensor modules?)'
> -		exit 1
> -	else
> -		SYSFS=1
> -		SENSDIR=$SDIR
> -	fi	
> -fi
> +SENSDIR=/sys/class/hwmon
> +HWMON=hwmon0
> +[ $2 ] && HWMON=$2

This usage of "test" isn't documented, so I'd rather avoid using it.
What about [ -n "$2" ] or [ $# -ge 2 ] instead?

> +SENS=$SENSDIR/$HWMON/device
>  
> -SENSDEV=$2
> -SENS=$SENSDIR/$SENSDEV
> -if [ ! -r $SENS ]
> +if [ ! -d $SENS ]
>  then
> -	echo $0: 'No sensors found! (modprobe sensor modules?)'
> +	echo "No sensors found in: $SENS"
> +	echo "(modprobe sensor modules?)"
>  	exit 1
>  fi
>  
>  STRING=N
> -if [ "$SYSFS" = "1" ]
> -then
>  	#
>  	# Get the value from these sensor files (/sys)
>  	#
>  	SENSORS="fan1 fan2 fan3"
>  	for i in $SENSORS
>  	do
> -		V="`cat $SENSDIR/$SENSDEV/${i}_input 2> /dev/null`"
> +	V="`cat $SENS/${i}_input 2> /dev/null`"
>  		if [ $? -ne 0 ]
>  		then
>  			STRING="${STRING}:U"
> @@ -81,7 +68,7 @@
>  	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"

Not related with your patch, but this list should be extended, we have
chips with up to temp6 and up to in10. Same for the fan list above, I
think we have up to fan7.

>  	for i in $SENSORS
>  	do
> -		V="`cat $SENSDIR/$SENSDEV/${i}_input 2> /dev/null`"
> +	V="`cat $SENS/${i}_input 2> /dev/null`"
>  		if [ $? -ne 0 ]
>  		then
>  			STRING="${STRING}:U"
> @@ -90,38 +77,6 @@
>  			STRING="${STRING}:${V}"
>  		fi
>  	done

You need to reindent the whole block. I know it will make the patch
bigger, but badly indented code is unmaintainable.

> -else
> -	#
> -	# Get the second value from these sensor files (/proc)
> -	#
> -	SENSORS="fan1 fan2 fan3"
> -	for i in $SENSORS
> -	do
> -		V="`cat $SENSDIR/$SENSDEV/$i 2> /dev/null`"
> -		if [ $? -ne 0 ]
> -		then
> -			STRING="${STRING}:U"
> -		else
> -			V="`echo $V | cut -d ' ' -f 2`"
> -			STRING="${STRING}:${V}"
> -		fi
> -	done
> -	#
> -	# Get the third value from these sensor files (/proc)
> -	#
> -	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
> -	for i in $SENSORS
> -	do
> -		V="`cat $SENSDIR/$SENSDEV/$i 2> /dev/null`"
> -		if [ $? -ne 0 ]
> -		then
> -			STRING="${STRING}:U"
> -		else
> -			V="`echo $V | cut -d ' ' -f 3`"
> -			STRING="${STRING}:${V}"
> -		fi
> -	done
> -fi
>  
>  #
>  # Get the first value from these /proc files

Patch looks good otherwise. Can you please update it and resubmit?

>  > You mentioned that sensors.conf.5 was out-of-date, can you please send
>  > a patch for it too?
> 
> I'm not sure how to fix some of this since I'm not really sure what
> the 2.6 equivalent is, but here are the lines that need adjusting:
> 
> 1.	The  second and third arguments are the description texts. They must
> 	be exactly match the texts as they appear  in  /proc/bus/i2c,
> 	except for trailing  spaces, which are removed both from the /proc entries
> 	and the arguments.
> 
> 	[I don't know where you find the 'second and third argument'
> 	(which are the chip description) in 2.6 kernels]
> 

Which version of the man page are you looking at? I updated that
section in October 2006.

> 2.	The  program  prog/config/grab_busses.sh in the source distribution
> 	can help you generate these lines.
> 
> 	[This program needs to be fixed for Kernel 2.6 -- I don't use it
> 	so I don't know exactly what it does or how to fix it]

It finds the current I2C buses numbers, and generates bus lines
suitable for sensors.conf. The idea is to run this script, copy the
output to sensors.conf, and use these bus numbers in the rest of the
configuration file. However, this is only needed if you have more than
one sensor chip of a given type *and* they need different
configurations - otherwise you simply give put the device name without
the bus number and address. So I guess that almost nobody needs this
script in practice, which explains why nobody ever complained that it
was broken for Linux 2.6. In fact the script is untouched since it was
created in December 1998!

So we have three options from here:
1* Kill the script and let people who really need bus lines build them
by hand. We can point them to i2cdetect, or simply to the output of
sensors.
2* Fix the grab_busses.sh script, probably by relying on "i2cdetect -l"
instead of /proc/bus/i2c.
3* Move the functionality to libsensors, and add a sensors option.

I wonder what the others think. I don't like option 2 because it adds a
dependency from sensors stuff to i2cdetect, while I'd like to get
rid of this dependency. (Especially as i2cdetect itself depends on the
i2c-dev driver being loaded for 2.6 kernels - another thing we should
fix.) So I'd go for option 1 for now, and possibly implement option 3
later if users really insist.

> 3.  The chip descriptions are equal to those appearing in
>     /proc/sys/dev/sensors, but may contain the * wildcard.
> 
> 	[Again, I don't know where you find the chip descriptions in 2.6
> 	kernels]

The chip descriptions no longer appear anywhere verbatim with 2.6
kernels. You have to build them up from the "name" device attribute,
the bus type and the device ID. How the chip descriptions are built is
already described right after in the manual page, so the best and
easiest fix for this one is probably to just drop the outdated
reference to /proc/sys/dev/sensors.

> More generally, you may want to have someone who is more familiar with
> the 'lm_sensors' project to review the full man page since it seems like
> it hasn't been changed since Feb 1999.

Not true. This man page has been updated 7 times since then. But this
man page is large an it isn't easy to keep all the sections up-to-date.

I've made a complete review of the chip statement section, hopefully
it's better now:
http://lm-sensors.org/changeset/4370

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jeffrey J. Kosowsky]

Jean Delvare wrote at about 21:02:22 +0200 on Tuesday, April 17, 2007:
 > On Tue, 17 Apr 2007 09:34:38 -0400, Jeffrey J. Kosowsky wrote:
 > This patch is better, however I still failed to apply it to our SVN
 > repository (hunk #2 failed). Was it generated cleanly? Does it apply
 > cleanly to 2.10.3 on your side? Better send the patches as attachments
 > if inline isn't reliable.

OK. Well since now almost all lines are rewritten (or at least
re-tabified), I am going to just include the full revised file and
circumvent any diff issues also that way.

 > > Here is the trimmed/streamlined version for 2.6 only:
 > > [Note I also made the sensor an optional input parameter that defaults
 > > to hwmon0 since that seems to be the most likely case for most users]
 > 
 > That's a good idea. That being said, systems with more than one
 > hardware monitoring device are becoming more popular.
....

 > > -if [ $# -ne 2 ]
 > > +if [ $# -lt 1 ]
 > 
 > Maybe test -gt 2 too, for completeness?

I rewrote the whole test thing for neatness and completeness (see below)

 > > +[ $2 ] && HWMON=$2
 > 
 > This usage of "test" isn't documented, so I'd rather avoid using it.
 > What about [ -n "$2" ] or [ $# -ge 2 ] instead?

OK. Changed and combined with first test for simplicity.

 > >  	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
 > 
 > Not related with your patch, but this list should be extended, we have
 > chips with up to temp6 and up to in10. Same for the fan list above, I
 > think we have up to fan7.

OK. But this would also require changing sens_day.cgi, sens_week.cgi,
summ_week.cgi.

Ideally, it would be great if the scripts would look at
/sys/class/hwmon/hwmonN/device/*input to see what the available inputs
are and then use that to determine what to store in and later retrieve
from the round robin database.

 
 > You need to reindent the whole block. I know it will make the patch
 > bigger, but badly indented code is unmaintainable.
Done. I re-tabified and (hopefully) properly indented all the code.
 
 > Patch looks good otherwise. Can you please update it and resubmit?
Here is the whole file:
NOTE: you may also need/want to update the copyright portion but I am
not sure what the right way to do it is...


#	 sens_update_rrd -
#	Update a sensors rrd database.
#	Sample usage:
#		sens_update_rrd /var/lib/database.rrd hwmon0
#	Sample cron entry:
#		*/5 * * * * /usr/local/bin/sens_update_rrd /var/lib/sensors-rrd/sensors.rrd hwmon0
#
#################################################################
#
#	 Copyright 2001,2005 Mark D. Studebaker <mdsxyz123@yahoo.com>
#
#	 This program is free software; you can redistribute it and/or modify
#	 it under the terms of the GNU General Public License as published by
#	 the Free Software Foundation; either version 2 of the License, or
#	 (at your option) any later version.
#
#	 This program is distributed in the hope that it will be useful,
#	 but WITHOUT ANY WARRANTY; without even the implied warranty of
#	 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#	 GNU General Public License for more details.
#
#	 You should have received a copy of the GNU General Public License
#	 along with this program; if not, write to the Free Software
#	 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
#################################################################
#
if [ $# -lt 1 -o $# -gt 2 ] ; then
	echo "usage: $0 database.rrd [hwmonN]"
	exit 1
elif [ $# -eq 2 ] ; then
	HWMON=$2
else
	HWMON=hwmon0
fi
#
RRDPATH=/usr/bin
RRDB=$1

SENSDIR=/sys/class/hwmon
SENS=$SENSDIR/$HWMON/device

if [ ! -d $SENS ] ; then
	echo "No sensors found in: $SENS"
	echo "(modprobe sensor modules?)"
	exit 1
fi

STRING=N
#
# Get the value from these sensor files (/sys)
#
SENSORS="fan1 fan2 fan3"
for i in $SENSORS ; do
	V="`cat $SENS/${i}_input 2> /dev/null`"
	if [ $? -ne 0 ] ; then
		STRING="${STRING}:U"
	else
		STRING="${STRING}:${V}"
	fi
done
#
# Get the value from these sensor files (/sys) and divide by 1000
#
SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
for i in $SENSORS ; do
	V="`cat $SENS/${i}_input 2> /dev/null`"
	if [ $? -ne 0 ] ; then
		STRING="${STRING}:U"
	else
		V=`echo "3k0 ${V/-/_} 1000/p"|dc`
		STRING="${STRING}:${V}"
	fi
done

#
# Get the first value from these /proc files
#
SENSORS="loadavg"
for i in $SENSORS ; do
	V="`cat /proc/$i 2> /dev/null`"
	if [ $? -ne 0 ]; then
		STRING="${STRING}:U"
	else
		V="`echo $V | cut -d ' ' -f 1`"
		STRING="${STRING}:${V}"
	fi
done

$RRDPATH/rrdtool update $RRDB $STRING


 > >  > You mentioned that sensors.conf.5 was out-of-date, can you please send
 > >  > a patch for it too?
 > > 
 > > I'm not sure how to fix some of this since I'm not really sure what
 > > the 2.6 equivalent is, but here are the lines that need adjusting:
 > > 
 > > 1.	The  second and third arguments are the description texts. They must
 > > 	be exactly match the texts as they appear  in  /proc/bus/i2c,
 > > 	except for trailing  spaces, which are removed both from the /proc entries
 > > 	and the arguments.
 > > 
 > > 	[I don't know where you find the 'second and third argument'
 > > 	(which are the chip description) in 2.6 kernels]
 > > 
 > 
 > Which version of the man page are you looking at? I updated that
 > section in October 2006.
Hmmm. I am using version 2.10-1 which is an update released in early
January 2007 for Fedora Core 6. But it sounds like the FC6 sources
are lagging


 > > 2.	The  program  prog/config/grab_busses.sh in the source distribution
 > > 	can help you generate these lines.
 > > 
 > > 	[This program needs to be fixed for Kernel 2.6 -- I don't use it
 > > 	so I don't know exactly what it does or how to fix it]
 > 
 > It finds the current I2C buses numbers, and generates bus lines
 > suitable for sensors.conf. The idea is to run this script, copy the
 > output to sensors.conf, and use these bus numbers in the rest of the
 > configuration file. However, this is only needed if you have more than
 > one sensor chip of a given type *and* they need different
 > configurations - otherwise you simply give put the device name without
 > the bus number and address. So I guess that almost nobody needs this
 > script in practice, which explains why nobody ever complained that it
 > was broken for Linux 2.6. In fact the script is untouched since it was
 > created in December 1998!
 > 
 > So we have three options from here:
 > 1* Kill the script and let people who really need bus lines build them
 > by hand. We can point them to i2cdetect, or simply to the output of
 > sensors.
 > 2* Fix the grab_busses.sh script, probably by relying on "i2cdetect -l"
 > instead of /proc/bus/i2c.
 > 3* Move the functionality to libsensors, and add a sensors option.
 > 
 > I wonder what the others think. I don't like option 2 because it adds a
 > dependency from sensors stuff to i2cdetect, while I'd like to get
 > rid of this dependency. (Especially as i2cdetect itself depends on the
 > i2c-dev driver being loaded for 2.6 kernels - another thing we should
 > fix.) So I'd go for option 1 for now, and possibly implement option 3
 > later if users really insist.
 > 
 > > 3.  The chip descriptions are equal to those appearing in
 > >     /proc/sys/dev/sensors, but may contain the * wildcard.
 > > 
 > > 	[Again, I don't know where you find the chip descriptions in 2.6
 > > 	kernels]
 > 
 > The chip descriptions no longer appear anywhere verbatim with 2.6
 > kernels. You have to build them up from the "name" device attribute,
 > the bus type and the device ID. How the chip descriptions are built is
 > already described right after in the manual page, so the best and
 > easiest fix for this one is probably to just drop the outdated
 > reference to /proc/sys/dev/sensors.
 > 
 > > More generally, you may want to have someone who is more familiar with
 > > the 'lm_sensors' project to review the full man page since it seems like
 > > it hasn't been changed since Feb 1999.
 > 
 > Not true. This man page has been updated 7 times since then. But this
 > man page is large an it isn't easy to keep all the sections up-to-date.
 > 
OK. Probably explained by Fedora still being on 2.10.1 so I have an
old manpage. Sorry about any confusion.

 > I've made a complete review of the chip statement section, hopefully
 > it's better now:
 > http://lm-sensors.org/changeset/4370
 > 

One more thing. Perhaps this is covered in your updated manpages, but
in the ones I have, I could not find any reference to
/sys/class/hwmon/. Had I known about this, it probably would have
saved much of this thread since the whole problem I had initially was
due to the non-fixed numbering of the sensors in the
/sys/bus/i2c/devices tree. So, if this is not currently in the
manpages, it may be helpful to add.

Finally, I wonder whether long term, it pays to revisit some of the
programs in the prog branch to see if they are still needed and
relevant. Some seem to be hidden and underutilized jewels while others
may be redundant or even obsolete (like grab_busses.sh). For example,
it seems to me that the sens_update.rrd approach has a lot of overlap
with the rrd functionality embedded in sensord (which can even be used
to generate cgi files). I continue to use the cgi scripts in the rrd
directory since I like them better but it might be a good idea to
think of unifying them in the future. Again, I am just a newbie here
so I may be missing something...

Jeff


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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Jeff,

On Tue, 17 Apr 2007 16:52:27 -0400, Jeffrey J. Kosowsky wrote:
> OK. Well since now almost all lines are rewritten (or at least
> re-tabified), I am going to just include the full revised file and
> circumvent any diff issues also that way.

OK. I've reverted some reformatting though, it's important that changes
are easily visible, and changing the coding style every now and then
really doesn't help history.

> > >  	SENSORS="temp1 temp2 temp3 in0 in1 in2 in3 in4 in5 in6"
> > 
> > Not related with your patch, but this list should be extended, we have
> > chips with up to temp6 and up to in10. Same for the fan list above, I
> > think we have up to fan7.
> 
> OK. But this would also require changing sens_day.cgi, sens_week.cgi,
> summ_week.cgi.

Ah, yes, good point. Let's forget about it for now then.

> Ideally, it would be great if the scripts would look at
> /sys/class/hwmon/hwmonN/device/*input to see what the available inputs
> are and then use that to determine what to store in and later retrieve
> from the round robin database.

Ideally, these scripts should not read the values directly from sysfs
in the first place, but should go through libsensors (using a binary
helper, ideally "sensors"), so that all the user configuration
in /etc/sensors.conf is honored. And libsensors would indeed scan sysfs
for usable sensor inputs automatically. But this goes far beyond just
fixing a few scripts - what we're talking about here is a complete
redesign and rewrite.

> NOTE: you may also need/want to update the copyright portion but I am
> not sure what the right way to do it is...

Well that's really up to you, you're the one working on updating this
script.

> -RRDPATH=/usr/local/rrdtool/bin
> +RRDPATH=/usr/bin

While I agree that the original value didn't make much sense, shouldn't
we simply rely on the $PATH to find the rrdtool binary instead of
hard-coding a directory? Also, this change should be reflected in the
Makefile and README files, and in the sens_create_rrd script, otherwise
it is inconsistent.

>  > I've made a complete review of the chip statement section, hopefully
>  > it's better now:
>  > http://lm-sensors.org/changeset/4370
> 
> One more thing. Perhaps this is covered in your updated manpages, but
> in the ones I have, I could not find any reference to
> /sys/class/hwmon/. Had I known about this, it probably would have
> saved much of this thread since the whole problem I had initially was
> due to the non-fixed numbering of the sensors in the
> /sys/bus/i2c/devices tree. So, if this is not currently in the
> manpages, it may be helpful to add.

/sys/class/hwmon is indeed not mentioned anywhere in the manual pages.
But /sys/bus/i2c/devices is not mentioned either, so how did you get
there? It looks to me like the primary cause of your problem is that
the code itself was outdated. Now that you fixed that, it should be
fine.

These sysfs interfaces should normally always be accessed through
libsensors and not directly, so I don't think we really want to
document them in manual pages, other than, maybe, the FILES section of
libsensors.3 (which doesn't exist yet.)

> Finally, I wonder whether long term, it pays to revisit some of the
> programs in the prog branch to see if they are still needed and
> relevant. Some seem to be hidden and underutilized jewels while others
> may be redundant or even obsolete (like grab_busses.sh). For example,
> it seems to me that the sens_update.rrd approach has a lot of overlap
> with the rrd functionality embedded in sensord (which can even be used
> to generate cgi files). I continue to use the cgi scripts in the rrd
> directory since I like them better but it might be a good idea to
> think of unifying them in the future. Again, I am just a newbie here
> so I may be missing something...

You are right, some of the programs are unmaintained and outdated. And
possibly some are redundant. We might improve the situation by dropping
or merging some of the tools, although in this case, both sensord and
sens_update_rrd are unmaintained anyway. But I tend to believe that
programs which are heavily used (such as sensors or fancontrol) get
updated rather quickly. Programs which aren't updated, are probably not
very much used. This is how the open-source model works: evolution.

The key issue here is that maintaining programs takes time, and this is
a scarce resource. Nobody seems to be interested in doing this. If you
want to help with that, you're welcome.

-- 
Jean Delvare

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jeffrey J. Kosowsky]

Jean Delvare wrote at about 20:35:55 +0200 on Thursday, April 19, 2007:
 > Hi Jeff,
 > 
 > OK. I've reverted some reformatting though, it's important that changes
 > are easily visible, and changing the coding style every now and then
 > really doesn't help history.

I see your point.
 
 > > Ideally, it would be great if the scripts would look at
 > > /sys/class/hwmon/hwmonN/device/*input to see what the available inputs
 > > are and then use that to determine what to store in and later retrieve
 > > from the round robin database.
 > 
 > Ideally, these scripts should not read the values directly from sysfs
 > in the first place, but should go through libsensors (using a binary
 > helper, ideally "sensors"), so that all the user configuration
 > in /etc/sensors.conf is honored. And libsensors would indeed scan sysfs
 > for usable sensor inputs automatically. But this goes far beyond just
 > fixing a few scripts - what we're talking about here is a complete
 > redesign and rewrite.

OK - we will save that for another round then.
 > 
 > > NOTE: you may also need/want to update the copyright portion but I am
 > > not sure what the right way to do it is...
 > 
 > Well that's really up to you, you're the one working on updating this
 > script.

I meant just that I don't know what the 'legal' or 'ethical' way
is. Do I just add the new years? Do I leave it alone? Do I add my name
(or others) if I end up making real changes? I just want to do the
right thing.

 > 
 > > -RRDPATH=/usr/local/rrdtool/bin
 > > +RRDPATH=/usr/bin
 > 
 > While I agree that the original value didn't make much sense, shouldn't
 > we simply rely on the $PATH to find the rrdtool binary instead of
 > hard-coding a directory? Also, this change should be reflected in the
 > Makefile and README files, and in the sens_create_rrd script, otherwise
 > it is inconsistent.

I agree. The hardcoding of paths rather than either using $PATH or
setting the variables in the Makefile is a huge PITA. It means that I
end up needing to add 'patch' files to patch the source when I build
my own rpms vs. just changing the inputs to 'make' or using some other
automated way of finding the binaries.


 > /sys/class/hwmon is indeed not mentioned anywhere in the manual pages.
 > But /sys/bus/i2c/devices is not mentioned either, so how did you get
 > there? It looks to me like the primary cause of your problem is that
 > the code itself was outdated. Now that you fixed that, it should be
 > fine.
 > 
 > These sysfs interfaces should normally always be accessed through
 > libsensors and not directly, so I don't think we really want to
 > document them in manual pages, other than, maybe, the FILES section of
 > libsensors.3 (which doesn't exist yet.)

OK. I don't know a lot about libsensors.
Is there any interface that would give you command line access to
libsensors. I know that you could always try to parse the output of
'sensors' but it might be nice to have more granular command line
access that would provide much of the same functionality as the
libsensors C-routines. If so, then scripts like sens_update.rrd could
just call those functions and you never would have to worry about the
/sys or /proc filesystem mechanics.

 > > Finally, I wonder whether long term, it pays to revisit some of the
 > > programs in the prog branch to see if they are still needed and
 > > relevant. Some seem to be hidden and underutilized jewels while others
 > > may be redundant or even obsolete (like grab_busses.sh). For example,
 > > it seems to me that the sens_update.rrd approach has a lot of overlap
 > > with the rrd functionality embedded in sensord (which can even be used
 > > to generate cgi files). I continue to use the cgi scripts in the rrd
 > > directory since I like them better but it might be a good idea to
 > > think of unifying them in the future. Again, I am just a newbie here
 > > so I may be missing something...
 > 
 > You are right, some of the programs are unmaintained and outdated. And
 > possibly some are redundant. We might improve the situation by dropping
 > or merging some of the tools, although in this case, both sensord and
 > sens_update_rrd are unmaintained anyway. But I tend to believe that
 > programs which are heavily used (such as sensors or fancontrol) get
 > updated rather quickly. Programs which aren't updated, are probably not
 > very much used. This is how the open-source model works: evolution.
 > 
 > The key issue here is that maintaining programs takes time, and this is
 > a scarce resource. Nobody seems to be interested in doing this. If you
 > want to help with that, you're welcome.

I will do my best to contribute wherever I can :)

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

Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes

[Jean Delvare]

Hi Jeff,

On Thu, 19 Apr 2007 14:50:51 -0400, Jeffrey J. Kosowsky wrote:
> Jean Delvare wrote at about 20:35:55 +0200 on Thursday, April 19, 2007:
>  > > NOTE: you may also need/want to update the copyright portion but I am
>  > > not sure what the right way to do it is...
>  > 
>  > Well that's really up to you, you're the one working on updating this
>  > script.
> 
> I meant just that I don't know what the 'legal' or 'ethical' way
> is. Do I just add the new years? Do I leave it alone? Do I add my name
> (or others) if I end up making real changes? I just want to do the
> right thing.

You can't touch other people's copyright, so just adding a year isn't
possible. You can either leave it untouched (as is now) or add your
own name with the new year. If you want to do that, just send a patch.

>  > > -RRDPATH=/usr/local/rrdtool/bin
>  > > +RRDPATH=/usr/bin
>  > 
>  > While I agree that the original value didn't make much sense, shouldn't
>  > we simply rely on the $PATH to find the rrdtool binary instead of
>  > hard-coding a directory? Also, this change should be reflected in the
>  > Makefile and README files, and in the sens_create_rrd script, otherwise
>  > it is inconsistent.
> 
> I agree. The hardcoding of paths rather than either using $PATH or
> setting the variables in the Makefile is a huge PITA. It means that I
> end up needing to add 'patch' files to patch the source when I build
> my own rpms vs. just changing the inputs to 'make' or using some other
> automated way of finding the binaries.

For now, I've updated the version in the 3.0.0 branch (for 2.6.14+
kernels) to use /usr/bin for rrd binaries by default, as you had
suggested.

I've also updated all the other files in the directory to reflect the
changes we made:
http://www.lm-sensors.org/changeset/4372
So it should be better now.

I even gave a try to this set of patches, to make sure I didn't break
anything. The least I can say is that it wasn't easy. Typical web
server installations expect you to put all your CGI programs in a
specific directory, and our scripts aren't compatible with this model,
so I had to edit them. I also noticed that the HTML code isn't exactly
state-of-the-art. Lots of cleanups would be needed to make it valid
HTML. And on top of that, I would have had to edit all the scripts to
change the inputs labels, disable some inputs and edit the scaling
factors, while I have a perfect board-specific sensors.conf file
already.

So while the resulting graphs look good (except the color... pink
graphs by default?!) I don't really expect that many users to go far
enough and actually use these scripts.

You are right that the user should be able to set up everything in the
Makefile. I wonder why the CGI scripts have their variables substituted
at build time, and the two shell scripts don't. The two shell scripts
should be provided as .in files, and "built" (variable substitution)
the same way. Want to give it a try (on the 3.0.0 branch)?

>  > /sys/class/hwmon is indeed not mentioned anywhere in the manual pages.
>  > But /sys/bus/i2c/devices is not mentioned either, so how did you get
>  > there? It looks to me like the primary cause of your problem is that
>  > the code itself was outdated. Now that you fixed that, it should be
>  > fine.
>  > 
>  > These sysfs interfaces should normally always be accessed through
>  > libsensors and not directly, so I don't think we really want to
>  > document them in manual pages, other than, maybe, the FILES section of
>  > libsensors.3 (which doesn't exist yet.)
> 
> OK. I don't know a lot about libsensors.
> Is there any interface that would give you command line access to
> libsensors. I know that you could always try to parse the output of
> 'sensors' but it might be nice to have more granular command line
> access that would provide much of the same functionality as the
> libsensors C-routines. If so, then scripts like sens_update.rrd could
> just call those functions and you never would have to worry about the
> /sys or /proc filesystem mechanics.

We could have a separate binary, but the best approach would be
additional command line parameters to "sensors", so that we can:
* retrieve the list of non-ignored inputs (name and type)
* query the converted value of a specific input
We don't have that at the moment, but it should be possible to add this
on top of the changes that are being made to the future version of
libsensors these days. Once we have that, writing scripts for sensors
stuff should be much more friendly.

-- 
Jean Delvare

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