Works now (Re: my user-space work ? (3d attempt))

Works now (Re: my user-space work ? (3d attempt))

[Danny Backx]

I'm sure I'm boring you by now. Sorry.

The names of the files in /sys were all different than what
chips.c said. This caused much of the mismatch. The hardcoded
file names are completely gone now. Voltage values start to
make sense :
dell: {227} prog/sensors/sensors
w83627hf-i2c-/sys/bus/i2c/devices/0-0290
Adapter: Dummy adapter
Algorithm: Dummy algorithm
in_input0:+14.40 V  (min = +12.16 V, max = +14.88 V)              
in_input1:+24.80 V  (min = +12.16 V, max = +14.88 V)              
in_input2:+33.44 V  (min = +29.76 V, max = +36.32 V)              
in_input3:+29.92 V  (min = +26.88 V, max = +32.64 V)              
in_input4:+31.52 V  (min = +28.48 V, max = +34.56 V)              
in_input5:+12.16 V  (min =  +3.36 V, max =  +7.84 V)              
in_input6:+15.04 V  (min =  +7.04 V, max = +10.24 V)              
in_input7:+32.80 V  (min = +26.88 V, max = +32.64 V)       ALARM  
in_input8:+32.96 V  (min = +27.04 V, max = +32.96 V)       ALARM  
fan_input1:
          1622 RPM  (min =  187 RPM, div = 32)                     
fan_input2:
          3013 RPM  (min =  187 RPM, div = 32)                     
fan_input3:
             0 RPM  (min =  375 RPM, div = 16)                     
temp_input1:
            +390?C  (limit =   +0?C, hysteresis =   +0?C) sensor thermistor           
temp_input2:
          +480.0?C  (limit =   +0?C, hysteresis =   +0?C) sensor PII/Celeron diode           
temp_input3:
          +2080.0?C  (limit =   +0?C, hysteresis =   +0?C) sensor thermistor           
vid:      +1.350 V
alarms:   
beep_enable:
          Sound alarm disabled

I'll leave it to you to figure out RPM and temperatures.

New patch included.

	Danny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-to-cvs.gz
Type: application/x-gzip
Size: 6921 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031011/794a8b4e/diff-to-cvs.gz

Works now (Re: my user-space work ? (3d attempt))

[Mark Studebaker]

so you have 'sensors' working on 2.6?
I'm having trouble understanding what you did from looking at the diff.
Could you explain if this is a general fix compatible for both 2.4 and
2.6 or
is there much more to do...
thanks
mds

Danny Backx wrote:
> 
> I'm sure I'm boring you by now. Sorry.
> 
> The names of the files in /sys were all different than what
> chips.c said. This caused much of the mismatch. The hardcoded
> file names are completely gone now. Voltage values start to
> make sense :
> dell: {227} prog/sensors/sensors
> w83627hf-i2c-/sys/bus/i2c/devices/0-0290
> Adapter: Dummy adapter
> Algorithm: Dummy algorithm
> in_input0:+14.40 V  (min = +12.16 V, max = +14.88 V)
> in_input1:+24.80 V  (min = +12.16 V, max = +14.88 V)
> in_input2:+33.44 V  (min = +29.76 V, max = +36.32 V)
> in_input3:+29.92 V  (min = +26.88 V, max = +32.64 V)
> in_input4:+31.52 V  (min = +28.48 V, max = +34.56 V)
> in_input5:+12.16 V  (min =  +3.36 V, max =  +7.84 V)
> in_input6:+15.04 V  (min =  +7.04 V, max = +10.24 V)
> in_input7:+32.80 V  (min = +26.88 V, max = +32.64 V)       ALARM
> in_input8:+32.96 V  (min = +27.04 V, max = +32.96 V)       ALARM
> fan_input1:
>           1622 RPM  (min =  187 RPM, div = 32)
> fan_input2:
>           3013 RPM  (min =  187 RPM, div = 32)
> fan_input3:
>              0 RPM  (min =  375 RPM, div = 16)
> temp_input1:
>             +390??C  (limit =   +0??C, hysteresis =   +0??C) sensor > thermistor
> temp_input2:
>           +480.0??C  (limit =   +0??C, hysteresis =   +0??C) sensor > PII/Celeron diode
> temp_input3:
>           +2080.0??C  (limit =   +0??C, hysteresis =   +0??C) sensor > thermistor
> vid:      +1.350 V
> alarms:
> beep_enable:
>           Sound alarm disabled
> 
> I'll leave it to you to figure out RPM and temperatures.
> 
> New patch included.
> 
>         Danny
> 
> 
>                      Name: diff-to-cvs.gz
>    diff-to-cvs.gz    Type: application/x-gzip
>                  Encoding: base64

Works now (Re: my user-space work ? (3d attempt))

[Danny Backx]

On Tue, 2003-10-21 at 03:12, Mark Studebaker wrote:
> so you have 'sensors' working on 2.6?

Yes

> I'm having trouble understanding what you did from looking at the diff.
> Could you explain if this is a general fix compatible for both 2.4 and
> 2.6 or is there much more to do...

I saw several things that needed to be ported, I'll explain
what I did and did not do.

The background is that I really don't know much about your code,
and I didn't take much time to learn about it (wrong, I know:-))
but I got much of the 2.4->2.6 port done. The parts not done,
or that need  review, are the parts where knowledge of the
sensors code is needed.

1. #define SENSORS_SYSFS
  I believe I've hidden my changes in #ifdefs based on that
  symbol.
2. /proc vs. sysfs
  I built code to look for the sysfs mount point (by reading
  /proc/mounts) and locate the right directory to read
  sensor data. This is all in sensors_read_proc_chips().

  On my system it locates /sys/bus/i2c/devices, sees that
  there's an entry 0-0290 in there (a symlink to a directory),
  in which it can find a file called "name" that contains
  the string "w83627hf" which is obviously my sensor chip.
  A small hack in the code is then to add "-*" to that
  string so it survives the sensors_parse_chip_name()
  function. You'll want to review this.

  Still in sensors_read_proc_chips(), I've stored the
  complete directory name that I found (e.g.
  /sys/bus/i2c/devices/0-0290) in the entry.name.busname
  field so I don't have to dig up all this info later on.
  This is visible in the first line of the output of
  sensors which displays that field. (See the sample
  output below.) 

3. I've duplicated some of the macros such as
  add_sys_chips() (was add_proc_chips). Not sure
  if this is useful. Also some duplicated structures
  like sensors_sys_chips_entry (sensors_proc_chips_entry).
  Again, please review.

4. In lib/access.c all the compares between sensor chip
  names were case sensitive. That made it fail for me.
  Changed all the calls of strcmp to strcasecmp for
  this reason.

5. Didn't know what to do with bus types. E.g. the
  function sensors_chip_name_has_wildcards() seemed to
  work on that so I disabled that check. Needs review.

  Similar for sensors_get_adapter_name() and
  sensors_get_algorithm_name() where I didn't understand
  what this should do so I basically disabled this
  by something like

	  const char *sensors_get_adapter_name(int bus_nr)
	  {
	+ #ifdef        SENSORS_SYSFS
	+       return "Dummy adapter";
	+ #else
	    int i;
	    if (bus_nr = SENSORS_CHIP_NAME_BUS_ISA)

6. The file names in /sys/bus/i2c/devices/0-0290 were
  different than the ones described in lib/chips.c so
  I changed some of them *for my adapter*. The files
  I see are called in_max0 etc where the code expected
  in0_max. I assume this is incompatibility between the
  code in kernel 2.6 and previous versions.

That's all, I think.

There are obvious problems with what I did in that the
temperature sensors give strange results - see below.

But as I said I really don't understand all this code so
I didn't feel like going after that.

Is this making sense ? Are there other things I can do ?

	Danny


> thanks
> mds


Sample output :
w83627hf-i2c-/sys/bus/i2c/devices/0-0290
Adapter: Dummy adapter
Algorithm: Dummy algorithm
in_input0:+14.40 V  (min = +12.16 V, max = +14.88 V)              
in_input1:+24.48 V  (min = +12.16 V, max = +14.88 V)              
in_input2:+33.28 V  (min = +29.76 V, max = +36.32 V)              
in_input3:+29.92 V  (min = +26.88 V, max = +32.64 V)              
in_input4:+31.52 V  (min = +28.48 V, max = +34.56 V)              
in_input5:+12.16 V  (min =  +3.36 V, max =  +7.84 V)              
in_input6:+15.04 V  (min =  +7.04 V, max = +10.24 V)              
in_input7:+32.80 V  (min = +26.88 V, max = +32.64 V)       ALARM  
in_input8:+32.96 V  (min = +27.04 V, max = +32.96 V)              
fan_input1:
          1622 RPM  (min =  187 RPM, div = 32)                     
fan_input2:
          2481 RPM  (min =  187 RPM, div = 32)                     
fan_input3:
             0 RPM  (min =  375 RPM, div = 16)                     
temp_input1:
            +370?C  (limit =   +0?C, hysteresis =   +0?C) sensor thermistor           
temp_input2:
          +450.0?C  (limit =   +0?C, hysteresis =   +0?C) sensor PII/Celeron diode           
temp_input3:
          +2080.0?C  (limit =   +0?C, hysteresis =   +0?C) sensor thermistor           
vid:      +1.350 V
alarms:   
beep_enable:
          Sound alarm disabled

Works now (Re: my user-space work ? (3d attempt))

[Jean Delvare]

> There are obvious problems with what I did in that the
> temperature sensors give strange results - see below.
> (...)
> Sample output :
> (...)
> temp_input1:
>             +370?C  (limit =   +0??C, hysteresis =   +0?C)
> temp_input2:
>           +450.0?C  (limit =   +0??C, hysteresis =   +0?C)
> temp_input3:
>           +2080.0?C  (limit =   +0??C, hysteresis =   +0?C)

These are 37, 45 and 208 degrees. Temperatures are stored in thousandth
of degrees. It had first been suggested that they would be in hundreds
of degrees, that might explain the error.

The 208 degrees has a special meaning, it of course isn't a real
temperature. This is a common output for unused/misconfigured
temperature sensors.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Works now (Re: my user-space work ? (3d attempt))

[Csaba Halasz]

On Wed, 2003-10-22 at 10:43, Danny Backx wrote:
> On Tue, 2003-10-21 at 03:12, Mark Studebaker wrote:
>> so you have 'sensors' working on 2.6?

> Yes

Me too. Got beaten by a couple of days :-)

>> I'm having trouble understanding what you did from looking at the diff.
>> Could you explain if this is a general fix compatible for both 2.4 and
>> 2.6 or is there much more to do...

> I saw several things that needed to be ported, I'll explain
> what I did and did not do.

> 2. /proc vs. sysfs

Yeah, me too.

> 3. I've duplicated some of the macros such as
>   add_sys_chips() (was add_proc_chips). Not sure
>   if this is useful. Also some duplicated structures
>   like sensors_sys_chips_entry (sensors_proc_chips_entry).
>   Again, please review.

I did something different. I just filled up the same
structures (chip and bus) from sysfs. Only trouble is
the algorithm, which I just left as "unknown" until
we have a way to get that info from sysfs as well.
(But nobody ever refers to it in their sensors.conf anyway :))

This way no other changes were necessary, making the
origin of the information completely transparent to
the rest of the library. 

> 4. In lib/access.c all the compares between sensor chip
>   names were case sensitive. That made it fail for me.
>   Changed all the calls of strcmp to strcasecmp for
>   this reason.

Didn't run into this one.

>  5. Didn't know what to do with bus types.
>   Similar for sensors_get_adapter_name() and
>   sensors_get_algorithm_name() where I didn't understand
>   what this should do so I basically disabled this
  
See 3. above.
Note that the adapter name _is_ available from sysfs.

> 6. The file names in /sys/bus/i2c/devices/0-0290 were
>   different than the ones described in lib/chips.c so
>   I changed some of them *for my adapter*. The files
>   I see are called in_max0 etc where the code expected
>   in0_max. I assume this is incompatibility between the
>   code in kernel 2.6 and previous versions.

Exactly what I did :)
If we want to keep compatibility, it might be a good idea
to introduce a new member, eg. sysfs_file_name.
(Or just change the sysfs names)

I came across two other problems though:

1) I don't know how to tell if a I2C device is a sensor.
   Maybe any device not mentioned in the config file
   should be ignored.

2) What about non-i2c devices? (ie. isa only) Where would
   they show up in sysfs?

Also, as far as I can tell, both Danny and I only fixed
the "sensors" prog (and similar 3rd party apps).
Other progs, for example sensors-detect, still don't work.

More precisely, we fixed the library. Therefore 
apps using _only_ the functions of the sensors library 
should work. Apps directly accessing /proc will not.

Patch coming sometime monday.

Greets,
	Csaba

Works now (Re: my user-space work ? (3d attempt))

[Mark Studebaker]

thanks for the explanation.

I want to ask the sensors team if they have comments on this approach,
and see if we have any volunteers to test and apply this patch and
work with Danny on enhancements.

Greg - is this the correct way to find sysfs?


Danny Backx wrote:
> 
> On Tue, 2003-10-21 at 03:12, Mark Studebaker wrote:
> > so you have 'sensors' working on 2.6?
> 
> Yes
> 
> > I'm having trouble understanding what you did from looking at the diff.
> > Could you explain if this is a general fix compatible for both 2.4 and
> > 2.6 or is there much more to do...
> 
> I saw several things that needed to be ported, I'll explain
> what I did and did not do.
> 
> The background is that I really don't know much about your code,
> and I didn't take much time to learn about it (wrong, I know:-))
> but I got much of the 2.4->2.6 port done. The parts not done,
> or that need  review, are the parts where knowledge of the
> sensors code is needed.
> 
> 1. #define SENSORS_SYSFS
>   I believe I've hidden my changes in #ifdefs based on that
>   symbol.
> 2. /proc vs. sysfs
>   I built code to look for the sysfs mount point (by reading
>   /proc/mounts) and locate the right directory to read
>   sensor data. This is all in sensors_read_proc_chips().
> 
>   On my system it locates /sys/bus/i2c/devices, sees that
>   there's an entry 0-0290 in there (a symlink to a directory),
>   in which it can find a file called "name" that contains
>   the string "w83627hf" which is obviously my sensor chip.
>   A small hack in the code is then to add "-*" to that
>   string so it survives the sensors_parse_chip_name()
>   function. You'll want to review this.
> 
>   Still in sensors_read_proc_chips(), I've stored the
>   complete directory name that I found (e.g.
>   /sys/bus/i2c/devices/0-0290) in the entry.name.busname
>   field so I don't have to dig up all this info later on.
>   This is visible in the first line of the output of
>   sensors which displays that field. (See the sample
>   output below.)
> 
> 3. I've duplicated some of the macros such as
>   add_sys_chips() (was add_proc_chips). Not sure
>   if this is useful. Also some duplicated structures
>   like sensors_sys_chips_entry (sensors_proc_chips_entry).
>   Again, please review.
> 
> 4. In lib/access.c all the compares between sensor chip
>   names were case sensitive. That made it fail for me.
>   Changed all the calls of strcmp to strcasecmp for
>   this reason.
> 
> 5. Didn't know what to do with bus types. E.g. the
>   function sensors_chip_name_has_wildcards() seemed to
>   work on that so I disabled that check. Needs review.
> 
>   Similar for sensors_get_adapter_name() and
>   sensors_get_algorithm_name() where I didn't understand
>   what this should do so I basically disabled this
>   by something like
> 
>           const char *sensors_get_adapter_name(int bus_nr)
>           {
>         + #ifdef        SENSORS_SYSFS
>         +       return "Dummy adapter";
>         + #else
>             int i;
>             if (bus_nr = SENSORS_CHIP_NAME_BUS_ISA)
> 
> 6. The file names in /sys/bus/i2c/devices/0-0290 were
>   different than the ones described in lib/chips.c so
>   I changed some of them *for my adapter*. The files
>   I see are called in_max0 etc where the code expected
>   in0_max. I assume this is incompatibility between the
>   code in kernel 2.6 and previous versions.
> 
> That's all, I think.
> 
> There are obvious problems with what I did in that the
> temperature sensors give strange results - see below.
> 
> But as I said I really don't understand all this code so
> I didn't feel like going after that.
> 
> Is this making sense ? Are there other things I can do ?
> 
>         Danny
> 
> > thanks
> > mds
> 
> Sample output :
> w83627hf-i2c-/sys/bus/i2c/devices/0-0290
> Adapter: Dummy adapter
> Algorithm: Dummy algorithm
> in_input0:+14.40 V  (min = +12.16 V, max = +14.88 V)
> in_input1:+24.48 V  (min = +12.16 V, max = +14.88 V)
> in_input2:+33.28 V  (min = +29.76 V, max = +36.32 V)
> in_input3:+29.92 V  (min = +26.88 V, max = +32.64 V)
> in_input4:+31.52 V  (min = +28.48 V, max = +34.56 V)
> in_input5:+12.16 V  (min =  +3.36 V, max =  +7.84 V)
> in_input6:+15.04 V  (min =  +7.04 V, max = +10.24 V)
> in_input7:+32.80 V  (min = +26.88 V, max = +32.64 V)       ALARM
> in_input8:+32.96 V  (min = +27.04 V, max = +32.96 V)
> fan_input1:
>           1622 RPM  (min =  187 RPM, div = 32)
> fan_input2:
>           2481 RPM  (min =  187 RPM, div = 32)
> fan_input3:
>              0 RPM  (min =  375 RPM, div = 16)
> temp_input1:
>             +370??C  (limit =   +0??C, hysteresis =   +0??C) sensor > thermistor
> temp_input2:
>           +450.0??C  (limit =   +0??C, hysteresis =   +0??C) sensor > PII/Celeron diode
> temp_input3:
>           +2080.0??C  (limit =   +0??C, hysteresis =   +0??C) sensor > thermistor
> vid:      +1.350 V
> alarms:
> beep_enable:
>           Sound alarm disabled

Works now (Re: my user-space work ? (3d attempt))

[Mark Studebaker]

I broke down and started integrating Danny's patch.
stay tuned for progress...

Mark Studebaker wrote:
> 
> thanks for the explanation.
> 
> I want to ask the sensors team if they have comments on this approach,
> and see if we have any volunteers to test and apply this patch and
> work with Danny on enhancements.
> 
> Greg - is this the correct way to find sysfs?
>