[lm-sensors] LM Sensors autoconfig tool project awarded as google

[lm-sensors] LM Sensors autoconfig tool project awarded as google

[Hans de Goede]

Hi All,

First of all apologies for not communicating and / or coordinating this 
with you earlier.

Besides writing the abituguru driver I'm also active (actually mainly 
active) as a Fedora contributer. A few weeks ago the Fedora board asked 
for ideas/projects for Fedora's participation in Google's Summer of Code 
(SOC: http://code.google.com/soc/). Ever since working on the abituguru 
driver I've had this dream / project in my head for better & easier 
autoconfiguration of lm_sensors for a specific setup.

Thus I took this chance to propose an lm_sensors autoconfig tool as a 
Fedora SOC project. As already said sorry for not involving you all 
earlier, I didn't expect much to come of this.

It has turned out however that much has come of this. 4 "students" have 
  submitted official applications to google to undertake this project! 
And 2 more have send me emails but didn't file their applications with 
google. And I have applicated to be the Mentor for one of these students 
who seems like an excellent candidate.

Its very likely (not 100% official yet) that this project will be 
approved and that the student I've applicated to Mentor will be working 
on this this summer.

Even though this is a Fedora project, I believe that the lm_sensors 
team/community getting involved is important if not vital and that the 
project should be implemented in an as distro neutral way as possible, 
hence my mail to you.

For the project as described by me when suggesting it see:
http://fedoraproject.org/wiki/FedoraBounties#head-5a66fb1f8ba2fa17d980e9d4df54c2b61e76ca54

As part of the application process the student has reworded this in his 
own words for his application, but since this isn't 100% official yet, 
so that ain't public yet. Suffice it to say that his application is much 
like my proposal.

Within the next week or so we (the student and I) must create a timeline 
and a clear set of deliverables which should be the end result of this 
project. I'll ask the student to subscribe to this list ASAP and to post 
and discuss a proposal here.

In the mean time it would help if you could read:
http://fedoraproject.org/wiki/FedoraBounties#head-5a66fb1f8ba2fa17d980e9d4df54c2b61e76ca
and give initial comments/feedback based on that.

Regards,

Hans

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Hi Hans,

> Besides writing the abituguru driver I'm also active (actually mainly 
> active) as a Fedora contributer. A few weeks ago the Fedora board asked 
> for ideas/projects for Fedora's participation in Google's Summer of Code 
> (SOC: http://code.google.com/soc/). Ever since working on the abituguru 
> driver I've had this dream / project in my head for better & easier 
> autoconfiguration of lm_sensors for a specific setup.
> 
> Thus I took this chance to propose an lm_sensors autoconfig tool as a 
> Fedora SOC project. As already said sorry for not involving you all 
> earlier, I didn't expect much to come of this.
> 
> It has turned out however that much has come of this. 4 "students" have 
>   submitted official applications to google to undertake this project! 
> And 2 more have send me emails but didn't file their applications with 
> google. And I have applicated to be the Mentor for one of these students 
> who seems like an excellent candidate.
> 
> Its very likely (not 100% official yet) that this project will be 
> approved and that the student I've applicated to Mentor will be working 
> on this this summer.
> 
> Even though this is a Fedora project, I believe that the lm_sensors 
> team/community getting involved is important if not vital and that the 
> project should be implemented in an as distro neutral way as possible, 
> hence my mail to you.
> 
> For the project as described by me when suggesting it see:
> http://fedoraproject.org/wiki/FedoraBounties#head-5a66fb1f8ba2fa17d980e9d4df54c2b61e76ca54

Sounds like a very good idea. A few users tried to setup similar
projects before, but nobody ever came up with something functional
enough to be used. If the project is completed and ends up being
operational, this would be a great improvement for the lm_sensors
project, making the setup phase much easier in many cases.

Using dmidecode to get the motherboard identification sounds right.
Note that I have implemented a command line interface to dmidecode,
which should come in handy:

$ dmidecode -s baseboard-manufacturer
Supermicro
$ dmidecode -s baseboard-product-name
370DL3/370DLE
$

This requires dmidecode >= 2.7.

A few comments about DMI tables:
* Depending on the system, the DMI table may be conveniently and
accurately filled, or empty, or useless. Systems with poor DMI tables
won't be supportable.
* Some systems have no type 2 (Base Board Information) DMI record but
do have type 1 (System Information) or type 3 (Chassis Information)
records you can fall back on.
* The full output of dmidecode can contain data which shouldn't be made
public (serial numbers, UUIDs etc.) so you must make sure to only ask
the user for what you need.

I don't think that being able to export the database is a key feature.
End users shouldn't need this.

Likewise, I don't like the hotplug/udev stuff you mention in point 2.
Configuration is only done once, so I don't quite see how hotplug is
relevant here. It's more simple, and more efficient too, to integrate
the motherboard recognition code into sensors-detect. If enough DMI
data is available, propose to connect to the online database to find a
configuration file. If a configuration file is found, copy it, and skip
all the probing phase. This is how I'd do it, anyway.

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> A few comments about DMI tables:
> * Depending on the system, the DMI table may be conveniently and
> accurately filled, or empty, or useless. Systems with poor DMI tables
> won't be supportable.

Yes I just encountered the first of such a system, any idea for
alternative methods to identify these? I'm myself thinking about
memmapping the bios and getting info from the bios image, anyone got any
experience with this?

Here is what my pcchips M811 gives:
Handle 0x0002, DMI type 2, 8 bytes.
Base Board Information
        Manufacturer:
        Product Name: VT8367-8235
        Version:
        Serial Number:

Clearly the didn't change this from the VIA reference bios.

> * Some systems have no type 2 (Base Board Information) DMI record but
> do have type 1 (System Information) or type 3 (Chassis Information)
> records you can fall back on.
The above motherboard doesn't contain any usefull info there either.

> I don't think that being able to export the database is a key feature.
> End users shouldn't need this.
> 

They will, one cannot assume a internet connection and even if one
assumes an internet connection, phoning home applications are evil!

> Likewise, I don't like the hotplug/udev stuff you mention in point 2.
> Configuration is only done once, so I don't quite see how hotplug is
> relevant here. 

The idea behind this is to make things truely plug and play, so if I
drop a new motherboard in my system the OS should reconfigure itself
automaticly and everything should work as if nothing has changed. I've
done this a couple of times and this currently works pretty well with
Linux as OS, except for lm_sensors.

> It's more simple, and more efficient too, to integrate
> the motherboard recognition code into sensors-detect. If enough DMI
> data is available, propose to connect to the online database to find a
> configuration file. If a configuration file is found, copy it, and skip
> all the probing phase. This is how I'd do it, anyway.
> 

See above, besides I want lm_sensors to just work (tm), having to run
sensors-detect is not just working. I do agree that the detected
motherboard should be stored somewhere and that the existing config
should not be overwritten if the motherboard wasn't changed.


Regards,

Hans

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Mark M. Hoffman]

Hi Hans:

First of all, thanks for taking the initiative to work on this.  It does
sound like a nice project for a student, and it is something that would
make lm-sensors usable for many more people.

> Jean Delvare wrote:
> > A few comments about DMI tables:
> > * Depending on the system, the DMI table may be conveniently and
> > accurately filled, or empty, or useless. Systems with poor DMI tables
> > won't be supportable.

* Hans de Goede <j.w.r.degoede at hhs.nl> [2006-05-30 12:36:22 +0200]:
> Yes I just encountered the first of such a system, any idea for
> alternative methods to identify these? I'm myself thinking about
> memmapping the bios and getting info from the bios image, anyone got any
> experience with this?

I don't know of any better ways to automatically identify mainboards.
However, I've been mulling over an idea to make manual configuration
easier.  Rather than distribute a single giant sensors.conf.eg as we
do now, we could distribute a tree of conf files, one per board:

/etc/sensors/
/etc/sensors/asus/
/etc/sensors/asus/p4s333.conf
/etc/sensors/asus/p4c800-e-deluxe.conf

It might be useful to enhance libsensors so that it can process
'#include' lines in the configuration file.  Since I have been
working on the analyzer & parser lately... if it turns out that
such functionality would be useful to you, I would offer to add it.

> Here is what my pcchips M811 gives:
> Handle 0x0002, DMI type 2, 8 bytes.
> Base Board Information
>         Manufacturer:
>         Product Name: VT8367-8235
>         Version:
>         Serial Number:
> 
> Clearly the didn't change this from the VIA reference bios.
> 
> > * Some systems have no type 2 (Base Board Information) DMI record but
> > do have type 1 (System Information) or type 3 (Chassis Information)
> > records you can fall back on.
> The above motherboard doesn't contain any usefull info there either.
> 
> > I don't think that being able to export the database is a key feature.
> > End users shouldn't need this.
> > 
> 
> They will, one cannot assume a internet connection and even if one
> assumes an internet connection, phoning home applications are evil!
> 
> > Likewise, I don't like the hotplug/udev stuff you mention in point 2.
> > Configuration is only done once, so I don't quite see how hotplug is
> > relevant here. 
> 
> The idea behind this is to make things truely plug and play, so if I
> drop a new motherboard in my system the OS should reconfigure itself
> automaticly and everything should work as if nothing has changed. I've
> done this a couple of times and this currently works pretty well with
> Linux as OS, except for lm_sensors.

I agree with you (Hans) here and about the database.  Actually, I *really*
like the idea of having a little DMI/hotplug driver, because that means
we *won't* have to add all of that directly to hwmon drivers.

> > It's more simple, and more efficient too, to integrate
> > the motherboard recognition code into sensors-detect. If enough DMI
> > data is available, propose to connect to the online database to find a
> > configuration file. If a configuration file is found, copy it, and skip
> > all the probing phase. This is how I'd do it, anyway.
> > 
> 
> See above, besides I want lm_sensors to just work (tm), having to run
> sensors-detect is not just working. I do agree that the detected
> motherboard should be stored somewhere and that the existing config
> should not be overwritten if the motherboard wasn't changed.

Thanks & regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Hi Hans, Mark,

> * Hans de Goede <j.w.r.degoede at hhs.nl> [2006-05-30 12:36:22 +0200]:
> > Yes I just encountered the first of such a system, any idea for
> > alternative methods to identify these? I'm myself thinking about
> > memmapping the bios and getting info from the bios image, anyone got any
> > experience with this?

I don't know of any alternative method. Best to fix the problem at its
root, and make the manufacturer fill in the DMI table properly in the
first place. A slow process, I know.

Mark Hoffman wrote:
> It might be useful to enhance libsensors so that it can process
> '#include' lines in the configuration file.  Since I have been
> working on the analyzer & parser lately... if it turns out that
> such functionality would be useful to you, I would offer to add it.

This would come in handy if we extend the database to contain not only
motherboards but also graphic adapters, for example.

> > Here is what my pcchips M811 gives:
> > Handle 0x0002, DMI type 2, 8 bytes.
> > Base Board Information
> >         Manufacturer:
> >         Product Name: VT8367-8235
> >         Version:
> >         Serial Number:
> > 
> > Clearly the didn't change this from the VIA reference bios.

Yup, same for my Fintek board:

Handle 0x0002
        DMI type 2, 8 bytes.
        Base Board Information
                Manufacturer:  
                Product Name: K8M800-8237
                Version:  
                Serial Number:  

I know there are BIOS updates available so I'll try this first. If the
latest BIOS doesn't fix it I'll contact Fintek.

> > > I don't think that being able to export the database is a key feature.
> > > End users shouldn't need this.
> > 
> > They will, one cannot assume a internet connection and even if one
> > assumes an internet connection, phoning home applications are evil!

One could argue that a 4 MB database on my hard disk drive, when I need
a single 3 kB file out of it, is evil. I have no problem with
applications phoning home as long as they ask me before. For systems
with no internet connection, people can download the file from the web
and copy it manually.

That being said, I am fine with both implementations, as long as it
works and the maintenance workload is limited.

> > > Likewise, I don't like the hotplug/udev stuff you mention in point 2.
> > > Configuration is only done once, so I don't quite see how hotplug is
> > > relevant here. 
> > 
> > The idea behind this is to make things truely plug and play, so if I
> > drop a new motherboard in my system the OS should reconfigure itself
> > automaticly and everything should work as if nothing has changed. I've
> > done this a couple of times and this currently works pretty well with
> > Linux as OS, except for lm_sensors.
> 
> I agree with you (Hans) here and about the database.  Actually, I *really*
> like the idea of having a little DMI/hotplug driver, because that means
> we *won't* have to add all of that directly to hwmon drivers.

Why would we have to add anything to the drivers?

I don't argue with the idea of a plug'n'play system. I argue strongly
against the proposed implementation. It really doesn't have anything
to do with hotplug (until your motherboard becomes hotpluggable...) and
the detection mechanism doesn't belong to the kernel. Userspace can
identify the motherboard and load the required modules, then configure
the chip(s) as needed. This only has to be done only once, at boot
time, and can easily be made part of the init scripts.

Unless I'm missing something. What do we win with an hotplug event?

> > > It's more simple, and more efficient too, to integrate
> > > the motherboard recognition code into sensors-detect. If enough DMI
> > > data is available, propose to connect to the online database to find a
> > > configuration file. If a configuration file is found, copy it, and skip
> > > all the probing phase. This is how I'd do it, anyway.
> > 
> > See above, besides I want lm_sensors to just work (tm), having to run
> > sensors-detect is not just working. I do agree that the detected
> > motherboard should be stored somewhere and that the existing config
> > should not be overwritten if the motherboard wasn't changed.

We agree on that second point. I don't agree with the statement that
"sensors-detect is not just working" though. sensors-detect does its
job well. If it fails on some systems, please report and we'll try to
fix that. Some things cannot be detected though (e.g. unused super-I/O
chips.) The real problem is that sensors-detect does only detect chips
and knows about which drivers they need. It was never meant to handle
the chips configuration, because this just can't be detected. The
project you propose would complement, not replace, sensors-detect.

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Rudolf Marek]

Hello,

SOme year ago I was investigating the same stuff - ID the motherboard with DMI.
I'm attaching some files from that period (july 2004 ;)

As far I can remember, only MSI was trouble..

Regards
Rudolf
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmicode
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060530/b512084c/dmicode-0001.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmidecode
Type: application/octet-stream
Size: 7059 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060530/b512084c/dmidecode-0001.obj
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmi_strucs
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060530/b512084c/dmi_strucs-0001.pl
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: getinfo
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060530/b512084c/getinfo-0001.pl

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Roger Lucas]

Hi All,

There was a similar thread on this list last year about how to set up a
system that automatically detects motherboards and their configurations.

We needed something to do this and our brief spec was for:
- a system that would confidently pick a configuration that was specific to
an exact motherboard, not based on chip probing.  This stopped any problems
with external voltage scaling resistors etc that were motherboard specific.
- a system that we could quickly add new configuation files to.
- a system with a standardised naming convention for the sensors themselves
so that the output from "sensors" could be easily parsed by a script or
similar and where the script did NOT need changing for different
motherboards.

Our solution was to create a unique sensors.conf file for each motherboard
which included information about the motherboard "dmidecode" output and the
modules that were needed to run.  A script ran the dmidecode utility and
scanned all the conf files in a folder looking for the best match.  It could
then optionally install the appropriate .conf file and add the appropriate
modprobe commands to the modules file.

We picked a naming convention for the sensors based on a prefix of:
	V_	voltage sensor
	T_	temperature sensor
	F_	Fan sensor

There then followed a unique identifier string - if it was a voltage rail
described as a target voltage (e.g. 3.3v rail) then we followed a typical
engineering practice of removing the "." and replacing it with "V" for
voltages.  A suffix of "P" indicated a positive voltage and "N" a negative
voltage - again common practice in schematics and similar.  If there were
multiple sensors reading the same type of parameter (e.g. multiple CPUs)
then a suffix of _0, _1, _2, ... was added.  This made the parser extremely
simple.

e.g.
    label in0 "V_VCORE_0"    #"VCore"
    label in2 "V_3V3P"    #"+3.3V"
    label in3 "V_5V0P"    #"+5V"
    label in4 "V_12V0P"    #"+12V"
    label in5 "V_12V0N"    #"-12V"
    label in6 "V_5V0N"    #"-5V"
    label in7 "V_V5SB"    #"V5SB"
    label in8 "V_VBAT"    #"VBat"

    label fan1 "F_CPU_0"
    label fan2 "F_MB_0"
    label fan3 "F_MB_1"
    label fan4 "F_MB_2"
    
    label temp1 "T_MB_0"
    label temp2 "T_CPU_0"

This has worked _really_ well for us.

I have attached the python script that we wrote as well as several sensors
files.  If this is of use to anyone then enjoy !

Comments welcome.

BR,

Roger
 
> -----Original Message-----
> From: lm-sensors-bounces at lm-sensors.org [mailto:lm-sensors-bounces at lm-
> sensors.org] On Behalf Of Hans de Goede
> Sent: 30 May 2006 11:36
> To: LM Sensors
> Subject: Re: [lm-sensors] LM Sensors autoconfig tool project awarded as
> google SOC project
> 
> 
> 
> Jean Delvare wrote:
> > Hi Hans,
> >
> > A few comments about DMI tables:
> > * Depending on the system, the DMI table may be conveniently and
> > accurately filled, or empty, or useless. Systems with poor DMI tables
> > won't be supportable.
> 
> Yes I just encountered the first of such a system, any idea for
> alternative methods to identify these? I'm myself thinking about
> memmapping the bios and getting info from the bios image, anyone got any
> experience with this?
> 
> Here is what my pcchips M811 gives:
> Handle 0x0002, DMI type 2, 8 bytes.
> Base Board Information
>         Manufacturer:
>         Product Name: VT8367-8235
>         Version:
>         Serial Number:
> 
> Clearly the didn't change this from the VIA reference bios.
> 
> > * Some systems have no type 2 (Base Board Information) DMI record but
> > do have type 1 (System Information) or type 3 (Chassis Information)
> > records you can fall back on.
> The above motherboard doesn't contain any usefull info there either.
> 
> > I don't think that being able to export the database is a key feature.
> > End users shouldn't need this.
> >
> 
> They will, one cannot assume a internet connection and even if one
> assumes an internet connection, phoning home applications are evil!
> 
> > Likewise, I don't like the hotplug/udev stuff you mention in point 2.
> > Configuration is only done once, so I don't quite see how hotplug is
> > relevant here.
> 
> The idea behind this is to make things truely plug and play, so if I
> drop a new motherboard in my system the OS should reconfigure itself
> automaticly and everything should work as if nothing has changed. I've
> done this a couple of times and this currently works pretty well with
> Linux as OS, except for lm_sensors.
> 
> > It's more simple, and more efficient too, to integrate
> > the motherboard recognition code into sensors-detect. If enough DMI
> > data is available, propose to connect to the online database to find a
> > configuration file. If a configuration file is found, copy it, and skip
> > all the probing phase. This is how I'd do it, anyway.
> >
> 
> See above, besides I want lm_sensors to just work (tm), having to run
> sensors-detect is not just working. I do agree that the detected
> motherboard should be stored somewhere and that the existing config
> should not be overwritten if the motherboard wasn't changed.
> 
> 
> Regards,
> 
> Hans
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abit_LG81.conf
Type: application/octet-stream
Size: 725 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/abit_LG81-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asrock_K7S41GX.conf
Type: application/octet-stream
Size: 3175 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/asrock_K7S41GX-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EPIA.conf
Type: application/octet-stream
Size: 2802 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/EPIA-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MSI_KM266-8237.conf
Type: application/octet-stream
Size: 3235 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/MSI_KM266-8237-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template.conf
Type: application/octet-stream
Size: 3091 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/template-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensors4mobo
Type: application/octet-stream
Size: 19047 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060531/01aca96f/sensors4mobo-0001.obj

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Mark M. Hoffman]

Hi Jean:

> > * Hans de Goede <j.w.r.degoede at hhs.nl> [2006-05-30 12:36:22 +0200]:
> > > They will, one cannot assume a internet connection and even if one
> > > assumes an internet connection, phoning home applications are evil!

* Jean Delvare <khali at linux-fr.org> [2006-05-30 14:32:33 +0200]:
> One could argue that a 4 MB database on my hard disk drive, when I need
> a single 3 kB file out of it, is evil. I have no problem with
> applications phoning home as long as they ask me before. For systems
> with no internet connection, people can download the file from the web
> and copy it manually.

A 4MB database is well into the noise for most distributions.  For any
that actually care, it should be easy to package the data separately.

> That being said, I am fine with both implementations, as long as it
> works and the maintenance workload is limited.
> 
> > > > Likewise, I don't like the hotplug/udev stuff you mention in point 2.
> > > > Configuration is only done once, so I don't quite see how hotplug is
> > > > relevant here. 
> > > 
> > > The idea behind this is to make things truely plug and play, so if I
> > > drop a new motherboard in my system the OS should reconfigure itself
> > > automaticly and everything should work as if nothing has changed. I've
> > > done this a couple of times and this currently works pretty well with
> > > Linux as OS, except for lm_sensors.
> > 
> > I agree with you (Hans) here and about the database.  Actually, I *really*
> > like the idea of having a little DMI/hotplug driver, because that means
> > we *won't* have to add all of that directly to hwmon drivers.
> 
> Why would we have to add anything to the drivers?
> 
> I don't argue with the idea of a plug'n'play system. I argue strongly
> against the proposed implementation. It really doesn't have anything
> to do with hotplug (until your motherboard becomes hotpluggable...) and
> the detection mechanism doesn't belong to the kernel. Userspace can
> identify the motherboard and load the required modules, then configure
> the chip(s) as needed. This only has to be done only once, at boot
> time, and can easily be made part of the init scripts.
> 
> Unless I'm missing something. What do we win with an hotplug event?

I had assumed that an auto-configurator would be driven by the kernel with
hotplug events.  But I guess you're right, it could be done just as well
without that.

> > > > It's more simple, and more efficient too, to integrate
> > > > the motherboard recognition code into sensors-detect. If enough DMI
> > > > data is available, propose to connect to the online database to find a
> > > > configuration file. If a configuration file is found, copy it, and skip
> > > > all the probing phase. This is how I'd do it, anyway.
> > > 
> > > See above, besides I want lm_sensors to just work (tm), having to run
> > > sensors-detect is not just working. I do agree that the detected
> > > motherboard should be stored somewhere and that the existing config
> > > should not be overwritten if the motherboard wasn't changed.
> 
> We agree on that second point. I don't agree with the statement that
> "sensors-detect is not just working" though. sensors-detect does its
> job well. If it fails on some systems, please report and we'll try to
> fix that. Some things cannot be detected though (e.g. unused super-I/O
> chips.) The real problem is that sensors-detect does only detect chips
> and knows about which drivers they need. It was never meant to handle
> the chips configuration, because this just can't be detected. The
> project you propose would complement, not replace, sensors-detect.

(If I may...) Hans is not saying that sensors-detect does not work.  For
the purpose of developers, it works well.  For the purpose of a user with
some courage or knowledge, it can also work.  But...

Go and give a talk to a local LUG about lm-sensors and you will find that
a lot of people will just wait for something like Hans' project to be
started and finished rather than wade into sensors-detect.  They're not
stupid either, and I don't blame them.  

Of course, free software being what it is... an automagic configurator
would have never made it to the top of my personal TODO list.  Anyone
who knows enough about lm-sensors to write a proper one doesn't actually
need it.  That said, once complete I probably will use it to save a tiny
amount of work (re-targeting a symlink or two) whenever I move a board
or a hard drive.

But for many users, something more automatic than sensors-detect could
mean the difference between using lm-sensors or not using it at all.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Mark, Hans,

> > > * Hans de Goede <j.w.r.degoede at hhs.nl> [2006-05-30 12:36:22 +0200]:
> > > > They will, one cannot assume a internet connection and even if one
> > > > assumes an internet connection, phoning home applications are evil!
> 
> * Jean Delvare <khali at linux-fr.org> [2006-05-30 14:32:33 +0200]:
> > One could argue that a 4 MB database on my hard disk drive, when I need
> > a single 3 kB file out of it, is evil. I have no problem with
> > applications phoning home as long as they ask me before. For systems
> > with no internet connection, people can download the file from the web
> > and copy it manually.
> 
> A 4MB database is well into the noise for most distributions.  For any
> that actually care, it should be easy to package the data separately.

Another advantage of the online approach is that data for new boards
can be added on a daily basis. I don't expect distributions to update
the database after the initial installation. So it might still make
sense to either integrate a database update mechanism in the user-space
tool, or at least to fallback on querying the online database directly
if the local database doesn't know anything about the motherboard.

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded

[Roger Lucas]

Hi Hans,

We use "sensors" as a back-end system for a GUI.  We didn't need to pick
this exact naming convention, but the example names in the sensors.conf file
were not consistent and we needed to pick a standard.  We didn't want to
have to re-write the GUI if we suddenly had a motherboard with an extra fan
input, so we needed a way for the sensor names to make sense to the GUI so
that it could adapt its display accordingly.  What I posted was our solution
to the problem.

There are many other solutions, but that was the one that we chose.  As a
general comment, however, in the *nix world, pretty much any utility that
only runs on the command line has to consider itself as a source of data for
other tools and should really try to make some effort to offer output (or at
least an optional output mode) which makes parsing its output by other
scripts easy.  All the LVM tools, for example, offer such modes as do tools
like dmidecode.  On the other hand, some of the SAMBA tools such as
smbstatus do not, and their output is very hard to reliably parse under
certain conditions.  I know which style of tools I prefer to work with...

I admit that the command-line mode is widely used in Linux, but so are
KDE/Gnome/xxxx-window-manager GUIs.  As I understand it, "sensors" is the
recommended tool for access to the lm-sensors subsystem, then its output
should be parseable so that the GUI can re-structure it as required.  As it
currently stands, there are a range of different description strings in
sensors.conf.  At the very least, if a centralised archive of sensors.conf
files is to be created then we need a naming convention for the sensor
values in just the same way that the sensor names themselves follow a
standard.  If we don't then anyone "downstream" of sensors will have a
horrible job trying to work out exactly what sensors they have and how to
display them.  If we want, we could have a short machine-style version and a
longer human style version.  I really don't mind, but for my needs, I need a
name that can be parsed easily and which is consistent across all the
motherboards that I am using (or may use in the future).

Best regards,

Roger


> -----Original Message-----
> From: Hans de Goede [mailto:j.w.r.degoede at hhs.nl]
> Sent: 31 May 2006 15:36
> To: Roger Lucas
> Subject: Re: [lm-sensors] LM Sensors autoconfig tool project awarded as
> google SOC project
> 
> Roger Lucas wrote:
> > Hi All,
> >
> 
> Hi,
> 
> Thanks for the config files, maybe its an idea to add them to the wiki?
> 
> >
> > We picked a naming convention for the sensors based on a prefix of:
> > 	V_	voltage sensor
> > 	T_	temperature sensor
> > 	F_	Fan sensor
> >
> > There then followed a unique identifier string - if it was a voltage
> rail
> > described as a target voltage (e.g. 3.3v rail) then we followed a
> typical
> > engineering practice of removing the "." and replacing it with "V" for
> > voltages.  A suffix of "P" indicated a positive voltage and "N" a
> negative
> > voltage - again common practice in schematics and similar.  If there
> were
> > multiple sensors reading the same type of parameter (e.g. multiple CPUs)
> > then a suffix of _0, _1, _2, ... was added.  This made the parser
> extremely
> > simple.
> >
> 
> I'm not sure I would want togo this way, I don't find the resulting
> names very pretty, with the Abit uGuru driver I've tried to match the
> names in sensors.conf to the BIOS names I think that that is what a less
> experienced user would expect.
> 
> Whats the advantage of this, why would you want to parse the output with
> a script?
> 
> Regards,
> 
> Hans

[lm-sensors] LM Sensors autoconfig tool project awarded

[Mark M. Hoffman]

Hi Roger:

* Roger Lucas <roger at planbit.co.uk> [2006-05-31 15:58:49 +0100]:
> We use "sensors" as a back-end system for a GUI.  We didn't need to pick
> this exact naming convention, but the example names in the sensors.conf file
> were not consistent and we needed to pick a standard.  We didn't want to
> have to re-write the GUI if we suddenly had a motherboard with an extra fan
> input, so we needed a way for the sensor names to make sense to the GUI so
> that it could adapt its display accordingly.  What I posted was our solution
> to the problem.
> 
> There are many other solutions, but that was the one that we chose.  As a
> general comment, however, in the *nix world, pretty much any utility that
> only runs on the command line has to consider itself as a source of data for
> other tools and should really try to make some effort to offer output (or at
> least an optional output mode) which makes parsing its output by other
> scripts easy.  All the LVM tools, for example, offer such modes as do tools
> like dmidecode.  On the other hand, some of the SAMBA tools such as
> smbstatus do not, and their output is very hard to reliably parse under
> certain conditions.  I know which style of tools I prefer to work with...
> 
> I admit that the command-line mode is widely used in Linux, but so are
> KDE/Gnome/xxxx-window-manager GUIs.  As I understand it, "sensors" is the
> recommended tool for access to the lm-sensors subsystem, then its output
> should be parseable so that the GUI can re-structure it as required.  As it

Really, you should use libsensors directly if that's your goal.  We're not
in the habit of making gratuitous changes to the output of sensors(1), but
AFAIK it's not considered a requirement.

BTW: the output of 'sensors -u' might be easier for you to parse.

> currently stands, there are a range of different description strings in
> sensors.conf.  At the very least, if a centralised archive of sensors.conf
> files is to be created then we need a naming convention for the sensor
> values in just the same way that the sensor names themselves follow a
> standard.  If we don't then anyone "downstream" of sensors will have a
> horrible job trying to work out exactly what sensors they have and how to
> display them.  If we want, we could have a short machine-style version and a
> longer human style version.  I really don't mind, but for my needs, I need a
> name that can be parsed easily and which is consistent across all the
> motherboards that I am using (or may use in the future).

The autoconfigurator will still allow custom /etc/sensors.conf I'm sure.  Is
there something else you need?

> > -----Original Message-----
> > From: Hans de Goede [mailto:j.w.r.degoede at hhs.nl]
> > Sent: 31 May 2006 15:36
> > To: Roger Lucas
> > Subject: Re: [lm-sensors] LM Sensors autoconfig tool project awarded as
> > google SOC project
> > 
> > Roger Lucas wrote:
> > > Hi All,
> > >
> > 
> > Hi,
> > 
> > Thanks for the config files, maybe its an idea to add them to the wiki?
> > 
> > >
> > > We picked a naming convention for the sensors based on a prefix of:
> > > 	V_	voltage sensor
> > > 	T_	temperature sensor
> > > 	F_	Fan sensor
> > >
> > > There then followed a unique identifier string - if it was a voltage
> > rail
> > > described as a target voltage (e.g. 3.3v rail) then we followed a
> > typical
> > > engineering practice of removing the "." and replacing it with "V" for
> > > voltages.  A suffix of "P" indicated a positive voltage and "N" a
> > negative
> > > voltage - again common practice in schematics and similar.  If there
> > were
> > > multiple sensors reading the same type of parameter (e.g. multiple CPUs)
> > > then a suffix of _0, _1, _2, ... was added.  This made the parser
> > extremely
> > > simple.
> > >
> > 
> > I'm not sure I would want togo this way, I don't find the resulting
> > names very pretty, with the Abit uGuru driver I've tried to match the
> > names in sensors.conf to the BIOS names I think that that is what a less
> > experienced user would expect.
> > 
> > Whats the advantage of this, why would you want to parse the output with
> > a script?
> > 
> > Regards,
> > 
> > Hans

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] LM Sensors autoconfig tool project awarded

[Roger Lucas]

Hi Mark,

> -----Original Message-----
> From: Mark M. Hoffman [mailto:mhoffman at lightlink.com]
> Sent: 01 June 2006 13:12
> To: Roger Lucas
> Cc: 'Hans de Goede'; 'LM Sensors'
> Subject: Re: [lm-sensors] LM Sensors autoconfig tool project awarded as
> google SOC project
> 
> Hi Roger:
> 
> * Roger Lucas <roger at planbit.co.uk> [2006-05-31 15:58:49 +0100]:
> > We use "sensors" as a back-end system for a GUI.  We didn't need to pick
> > this exact naming convention, but the example names in the sensors.conf
> file
> > were not consistent and we needed to pick a standard.  We didn't want to
> > have to re-write the GUI if we suddenly had a motherboard with an extra
> fan
> > input, so we needed a way for the sensor names to make sense to the GUI
> so
> > that it could adapt its display accordingly.  What I posted was our
> solution
> > to the problem.
> >
> > There are many other solutions, but that was the one that we chose.  As
> a
> > general comment, however, in the *nix world, pretty much any utility
> that
> > only runs on the command line has to consider itself as a source of data
> for
> > other tools and should really try to make some effort to offer output
> (or at
> > least an optional output mode) which makes parsing its output by other
> > scripts easy.  All the LVM tools, for example, offer such modes as do
> tools
> > like dmidecode.  On the other hand, some of the SAMBA tools such as
> > smbstatus do not, and their output is very hard to reliably parse under
> > certain conditions.  I know which style of tools I prefer to work
> with...
> >
> > I admit that the command-line mode is widely used in Linux, but so are
> > KDE/Gnome/xxxx-window-manager GUIs.  As I understand it, "sensors" is
> the
> > recommended tool for access to the lm-sensors subsystem, then its output
> > should be parseable so that the GUI can re-structure it as required.  As
> it
> 
> Really, you should use libsensors directly if that's your goal.  We're not
> in the habit of making gratuitous changes to the output of sensors(1), but
> AFAIK it's not considered a requirement.
> 

If you are writing C code then yes, and for the KDE/Gnome/XXX example I gave
this is true.  We also use web monitoring pages, however, and these are
generated from PHP and shell scripts.  I don't know how to directly access
libsensors from PHP or a bash script.

> BTW: the output of 'sensors -u' might be easier for you to parse.

Definitely much easier to parse than the plain "sensors" output.  But
according to the man page, the "-u" treats all chips as unknown.  The output
from "sensors -u", however, correctly identifies the chips and uses the
correct sensors.conf section, so I think the man page needs an update here
to more clearly describe what the "-u" option does.

> 
> > currently stands, there are a range of different description strings in
> > sensors.conf.  At the very least, if a centralised archive of
> sensors.conf
> > files is to be created then we need a naming convention for the sensor
> > values in just the same way that the sensor names themselves follow a
> > standard.  If we don't then anyone "downstream" of sensors will have a
> > horrible job trying to work out exactly what sensors they have and how
> to
> > display them.  If we want, we could have a short machine-style version
> and a
> > longer human style version.  I really don't mind, but for my needs, I
> need a
> > name that can be parsed easily and which is consistent across all the
> > motherboards that I am using (or may use in the future).
> 
> The autoconfigurator will still allow custom /etc/sensors.conf I'm sure.
> Is
> there something else you need?

Is there a spec anywhere for this autoconfigurator?  Han's early link is
still very thin on the details and the Google SOC doesn't list this sensors
project that I can see.


> 
> Regards,
> 
> --
> Mark M. Hoffman
> mhoffman at lightlink.com

Thanks,

Roger

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans:
> 
> I don't know of any better ways to automatically identify mainboards.
> However, I've been mulling over an idea to make manual configuration
> easier.  Rather than distribute a single giant sensors.conf.eg as we
> do now, we could distribute a tree of conf files, one per board:
> 
> /etc/sensors/
> /etc/sensors/asus/
> /etc/sensors/asus/p4s333.conf
> /etc/sensors/asus/p4c800-e-deluxe.conf
> 

I personally think this is a good idea, but how big will this become? 
Any idea how many motherboards there are out there? lots but how much?

> It might be useful to enhance libsensors so that it can process
> '#include' lines in the configuration file.  Since I have been
> working on the analyzer & parser lately... if it turns out that
> such functionality would be useful to you, I would offer to add it.
> 

Yes that would be very usefull, So that we can have a manually editable 
file for who knows what which then includes the autogenerated one or 
vica versa.

Thanks & regards,

Hans

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Hi Roger,

> > BTW: the output of 'sensors -u' might be easier for you to parse.
> 
> Definitely much easier to parse than the plain "sensors" output.  But
> according to the man page, the "-u" treats all chips as unknown.  The output
> from "sensors -u", however, correctly identifies the chips and uses the
> correct sensors.conf section, so I think the man page needs an update here
> to more clearly describe what the "-u" option does.

-u means that a generic printing routine is used, instead of the chip
specific one. This is what was meant with "unknown chip". I agree the
help is maybe not very clear, patches are welcome.

In an ideal world, all chips would be printed properly by the generic
printing routine and we wouldn't even need chip specific ones. This is
where we are heading with the sysfs interface standard. But as long as
libsensors must be told about all symbols for each chip (as opposed to
dir scan/discovery) this doesn't present much interest, unfortunately.

> Is there a spec anywhere for this autoconfigurator?  Han's early link is
> still very thin on the details and the Google SOC doesn't list this sensors
> project that I can see.

Look at entry "The Fedora Project".

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Hi Hans,

> > I don't know of any better ways to automatically identify mainboards.
> > However, I've been mulling over an idea to make manual configuration
> > easier.  Rather than distribute a single giant sensors.conf.eg as we
> > do now, we could distribute a tree of conf files, one per board:
> > 
> > /etc/sensors/
> > /etc/sensors/asus/
> > /etc/sensors/asus/p4s333.conf
> > /etc/sensors/asus/p4c800-e-deluxe.conf
> 
> I personally think this is a good idea, but how big will this become? 
> Any idea how many motherboards there are out there? lots but how much?

The Motherboard Monitor project had around 1100 known motherboards when
it stopped 2 years ago. So depending on how successful we get, the
number of configuration files could range from a few hundreds to 2000
or so.

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
>>> I don't know of any better ways to automatically identify mainboards.
>>> However, I've been mulling over an idea to make manual configuration
>>> easier.  Rather than distribute a single giant sensors.conf.eg as we
>>> do now, we could distribute a tree of conf files, one per board:
>>>
>>> /etc/sensors/
>>> /etc/sensors/asus/
>>> /etc/sensors/asus/p4s333.conf
>>> /etc/sensors/asus/p4c800-e-deluxe.conf
>> I personally think this is a good idea, but how big will this become? 
>> Any idea how many motherboards there are out there? lots but how much?
> 
> The Motherboard Monitor project had around 1100 known motherboards when
> it stopped 2 years ago. So depending on how successful we get, the
> number of configuration files could range from a few hundreds to 2000
> or so.
> 

Say worst case scenario is 2000 files each taking 4kb that sums up to
8Mb diskspace, sounds acceptable to me, what do others think?

Regards,

Hans

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Roger Lucas]

> >
> > The Motherboard Monitor project had around 1100 known motherboards when
> > it stopped 2 years ago. So depending on how successful we get, the
> > number of configuration files could range from a few hundreds to 2000
> > or so.
> >
> 
> Say worst case scenario is 2000 files each taking 4kb that sums up to
> 8Mb diskspace, sounds acceptable to me, what do others think?
> 

That doesn't sound that big, but it will continue to grow.  The files are
text files, however, and there will be significant common text between them
so I would expect that gzip'd TAR of them would dramatically reduce their
size.  If any tool could work with a tgz archive rather than requiring the
files directly then this could save a lot of space on the disk.

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Jean Delvare]

Hi Roger, Hans,

> > Say worst case scenario is 2000 files each taking 4kb that sums up to
> > 8Mb diskspace, sounds acceptable to me, what do others think?

I admit it's acceptable by today's standards, but given that it's 5
times the size of lm_sensors itself (user-space part), I'd expect
distributions to ship it as a separate, optional package. And we
probably should do as well.

> That doesn't sound that big, but it will continue to grow.  The files are
> text files, however, and there will be significant common text between them
> so I would expect that gzip'd TAR of them would dramatically reduce their
> size.  If any tool could work with a tgz archive rather than requiring the
> files directly then this could save a lot of space on the disk.

Storing the base as a tar.gz file would probably slow down its use
(maybe not that much) and will also make hacking harder (how do I add
or modify a file for test purposes?) I was about to suggest
compressing individual configuration files instead (as commonly done
with manual pages) but I just realized it wouldn't spare much space, if
at all, as in most cases configuration files tend to be smaller than
the node size of the file system anyway.

Anyway this is an implementation detail which can be addressed
afterwards if needed.

-- 
Jean Delvare

[lm-sensors] LM Sensors autoconfig tool project awarded as

[Henrik Brix Andersen]

On Sat, Jun 03, 2006 at 11:50:32AM +0200, Jean Delvare wrote:
> I admit it's acceptable by today's standards, but given that it's 5
> times the size of lm_sensors itself (user-space part), I'd expect
> distributions to ship it as a separate, optional package. And we
> probably should do as well.

I agree. Shipping it as a seperate package will also allow more
experienced users to download it and extract the one file they need to
their file system to reduce the disk space requirements.

Regards,
Brix
-- 
Henrik Brix Andersen <brix at gentoo.org>
Gentoo Metadistribution | Mobile computing herd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060603/607d421f/attachment.bin 

[lm-sensors] LM Sensors autoconfig tool project awarded

[Hans de Goede]

On Sat, Jun 03, 2006 at 11:50:32AM +0200, Jean Delvare wrote:
> I admit it's acceptable by today's standards, but given that it's 5
> times the size of lm_sensors itself (user-space part), I'd expect
> distributions to ship it as a separate, optional package. And we
> probably should do as well.
> 

I've thought some more about this and I must say I like the idea, if we
have a package* containing known working config files for each
motherboard and an include statement for sensors.conf, then an
autoconfig tool would only have to generate the nescesarry #include
lines(s). This way it will also be easy to generate configs which
contain the correct config for both a motherboard and say a graphics
card, simply by having 2 include lines in sensors.conf one for each.

*preferably a package generated from some kinda database with a
webinterface, as will be created by the google SOC project)


Regards,

Hans