[lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[Andre Prendel]

Hello Jean, Hans,

a long time ago we've spoken about "DMI-based
configuration". Unfortunately the last half year I only had a very
reduced amount of time. But today I send my first proposal (patch) for
this issue :)

A few words...

The tool is written in Python. I hope you can live with
this although this is another language in the lm-sensors project. I like
the object oriented modules of Python and IMHO Python should be
installed on every machine in a default installation.

What can you do with this tool?

1. Download config files from lm-sensors.org and build an archive
2. Install this archive into the file system (the path is hard-coded
so far)
3. List the vendors off the available configs
4. List the board configs of a vendor
5. Install a config by vendor and board name
6. Show your systems' DMI data
7. Search a config based on the DMI data and install them
8. Remove the configs from the file system

NOTE: This is an early version. There are plenty of ToDos and probably
some bugs. This is a request for comments what do you thing about the
tool.

And now a short introduction.

To see a short help type

  ./sensors-config.py -h

Download and build archive
==============
1. First you have to create an directory for downloading.

  andre@andre-laptop:~/src/sensors/prog/detect$ mkdir configs

2. Change to this directory

  andre@andre-laptop:~/src/sensors/prog/detect$ cd configs/

3. Download the configs and build archive

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ ../sensors-config.py -t
  Fetch config for Evga/x58-SLI
  Fetch config for ASRock/AM2NF3-VSTA
  Fetch config for Epox/M1697
  Fetch config for Epox/MF4-Ultra3
  Fetch config for Abit/AA8-DuraMAX
  Fetch config for Abit/AA8XE-Fatal1ty
  Fetch config for Abit/AI7
  Fetch config for Abit/AN7
  Fetch config for Abit/AN8-SLI
  Fetch config for Abit/AV8
  Fetch config for Abit/AX8
  Fetch config for Abit/Aa7-Max
  Fetch config for Abit/Ag7
  Fetch config for Abit/KN9-Ultra
  Fetch config for Abit/KV8-MAX3
  Fetch config for Abit/Kv8Pro
  Fetch config for Abit/VA-20
  Fetch config for DFI/CFX3200-M2-G-infinity
  Fetch config for DFI/Lanparty NF4 Expert
  Fetch config for DFI/Lanparty UT 790FX
  Fetch config for Asus/KFN4-DRE
  Fetch config for Asus/M2N-SLI Deluxe

The files are downloaded, some of unneeded "data" is stripped and an
tarball is build in the same directory.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ ls -l
  insgesamt 32
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Abit
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 ASRock
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Asus
  -rw-r--r-- 1 andre andre 5569 2010-01-13 21:11 configuration.tar.gz
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 DFI
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Epox
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Evga

This behaviour should be optimized. The directory should be created
automatically and the configs should be removed. At the moment only a
few configs are fetch from lm-sensors.org. Look at the configs hash in
the source code.


Install the configuration from the archive
=====================

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \
  ../sensors-config.py -a configuration.tar.gz

This installs the configs to /usr/local/share/sensors/conf. So far the
path is hard-coded. This should be changed.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ ls -l \
  /usr/local/share/sensors/conf/
  insgesamt 24
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Abit
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 ASRock
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Asus
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 DFI
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Epox
  drwxr-xr-x 2 andre andre 4096 2010-01-13 21:11 Evga


List the available configurations
================
To list all the vendors use -l option.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ \
  ../sensors-config.py -l
  ASRock
  Abit
  Asus
  DFI
  Epox
  Evga

To list the boards of a given vendor use -b option.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ \
  ../sensors-config.py -b Abit
  AA8-DuraMAX
  AA8XE-Fatal1ty
  AI7
  AN7
  AN8-SLI
  AV8
  AX8
  Aa7-Max
  Ag7
  KN9-Ultra
  KV8-MAX3
  Kv8Pro
  VA-20


Install a configuration
===========
You can manually install a configuration use -i option and an argument
in the format VENDOR/BOARD.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \
  ../sensors-config.py -i Abit/VA-20

This install the VA-20 config from Abit into /etc/sensors.d.

ATTENTION: This will overwrite all the existing configs in
/etc/sensors.d.

You can also install a config based on DMI data. To show your
systems' DMI data use -d.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$
  ../sensors-config.py -d
  board_name: 8918DFG
  board_vendor: LENOVO
  board_version: Not Available
  chassis_type: 10
  product_name: 8918DFG
  product_version: ThinkPad R61
  sys_vendor: LENOVO

To search for a suitable config use -f. There are two options to find
a config although there is no one suitable for your DMI data. Use
option -V VENDOR and -B BOARD to overwrite the systems' DMI data. So
you can simulate another machine.

  andre@andre-laptop:~/src/sensors/prog/detect/configs$ sudo \
  ../sensors-config.py -f -V Abit -B VA-20
  Found a suitable configuration: Abit/VA-20
  Do you want to install this configuration? [y/N]: y
  This will delete older configurations. Do you want to proceed? [y/N]: y

Now the VA-20 config file should be installed in /etc/sensors.d.

Ok, that's for the moment. There are much work left. Have fun and I'de
be happy to hear from you.

Thanks,
Andre

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

Re: [lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[Hans de Goede]

Hi Andre,

Thanks for working on this!

On 01/13/2010 09:56 PM, Andre Prendel wrote:
> Hello Jean, Hans,
>
> a long time ago we've spoken about "DMI-based
> configuration". Unfortunately the last half year I only had a very
> reduced amount of time. But today I send my first proposal (patch) for
> this issue :)
>
> A few words...
>
> The tool is written in Python. I hope you can live with
> this although this is another language in the lm-sensors project. I like
> the object oriented modules of Python and IMHO Python should be
> installed on every machine in a default installation.
>

Hmm, I don't mind the archive download and building tool being written
in python. But eventually there should also be a bash script which
can be run from the systems initscript which will automatically
find a config based on dmi and if found copy it to /etc/sensors-mb.conf
(which can then be included from the regular sensors.conf). I don't
think this part should be in python as on most systems none of the
other initscripts use python.

> What can you do with this tool?
>
> 1. Download config files from lm-sensors.org and build an archive

Hmm, I see it currently has a hardcoded list of config files, it would
be good if it could discover the config files dynamically based on
what is available on lm-sensors.org

> 2. Install this archive into the file system (the path is hard-coded
> so far)

I think the path should be under /var/lib, as the contents can
change by running the same version of the tool again (if the
wiki is updated).

> 3. List the vendors off the available configs
> 4. List the board configs of a vendor
> 5. Install a config by vendor and board name
> 6. Show your systems' DMI data
> 7. Search a config based on the DMI data and install them

I see currently this assumes that the name as on the wiki (in
the url on the wiki), is the same as in the dmi info, this is
not necessarily true. There was a project similar to yours a
while ago, which added magic comments to the config files
to state for which dmi strings the config was valid. note
that one config could be valid for multiple boards.

> 8. Remove the configs from the file system
>
> NOTE: This is an early version. There are plenty of ToDos and probably
> some bugs. This is a request for comments what do you thing about the
> tool.
>

Disclaimer: I have not tested it.

What I think, well I like that someone is working on this, and I like
that you are using the wiki as "database", as with previous attempts
part of the problem was that both a tool and a website needed to
be developed simultaneously.

As for comments, see above.

Thanks & Regards,

Hans

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

Re: [lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[Andre Prendel]

On Thu, Jan 14, 2010 at 11:35:33AM +0100, Hans de Goede wrote:
> Hi Andre,

Hi Hans,

Thanks for your feedback :)

> Thanks for working on this!
> 
> On 01/13/2010 09:56 PM, Andre Prendel wrote:
> >Hello Jean, Hans,
> >
> >a long time ago we've spoken about "DMI-based
> >configuration". Unfortunately the last half year I only had a very
> >reduced amount of time. But today I send my first proposal (patch) for
> >this issue :)
> >
> >A few words...
> >
> >The tool is written in Python. I hope you can live with
> >this although this is another language in the lm-sensors project. I like
> >the object oriented modules of Python and IMHO Python should be
> >installed on every machine in a default installation.
> >
> 
> Hmm, I don't mind the archive download and building tool being written
> in python. But eventually there should also be a bash script which
> can be run from the systems initscript which will automatically
> find a config based on dmi and if found copy it to /etc/sensors-mb.conf
> (which can then be included from the regular sensors.conf). I don't
> think this part should be in python as on most systems none of the
> other initscripts use python.

What do you mean with this /etc/sensors-mb.conf? I don't know such a
config file. My plan was to copy the file to the /etc/sensors.d
directory. Configs in this directory overwrites the default
sensors.conf config file.

I don't think we have to copy the file on every startup. It should be
enough to do this while installing lm-sensors or if an update is
available, right? But it's right, we need an trigger for the dmi-based
configuration. This could be done from 'make install'.

Just a few words about my intention how to use the config-tool.

The fetching and archive building part is only for config maintainers
(e.g. you, Jean or me). If a new config is available or something
changed a maintainer builds a new archive. This archive should be
provided via lm-sensors.org.

User can download the archive and use the config-tool the install
it. We could improve the tool to inform the user for new updates and
download the archive automatically.

> >What can you do with this tool?
> >
> >1. Download config files from lm-sensors.org and build an archive
> 
> Hmm, I see it currently has a hardcoded list of config files, it would
> be good if it could discover the config files dynamically based on
> what is available on lm-sensors.org

That's right. We could maintain a file similar to the format generated
by the wiki.

  http://lm-sensors.org/wiki/Configurations

Such a file is easy to parse and might contain only confirmed
configurations. Or do you know a way to scan remote directories via
HTTP?

> >2. Install this archive into the file system (the path is hard-coded
> >so far)
> 
> I think the path should be under /var/lib, as the contents can
> change by running the same version of the tool again (if the
> wiki is updated).

It seems you're right again. The FHS says data in /usr/share must be
purely static data. I will change the path.

> >3. List the vendors off the available configs
> >4. List the board configs of a vendor
> >5. Install a config by vendor and board name
> >6. Show your systems' DMI data
> >7. Search a config based on the DMI data and install them
> 
> I see currently this assumes that the name as on the wiki (in
> the url on the wiki), is the same as in the dmi info, this is
> not necessarily true.

The names don't have to exactly match. The lookup is case-insensitiv
and the "wiki name" have to be part of the "dmi name". I did some test
with the data Rudolf Marek sent in the first thread.

  http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018982.html

> There was a project similar to yours a
> while ago, which added magic comments to the config files
> to state for which dmi strings the config was valid. note
> that one config could be valid for multiple boards.

Yes, one config for multiple boards doesn't work at the
moment. Probably we have to introduce some meta data for this
issue. Maybe we could support single boards for now and add this
feature later on!?

> >8. Remove the configs from the file system
> >
> >NOTE: This is an early version. There are plenty of ToDos and probably
> >some bugs. This is a request for comments what do you thing about the
> >tool.
> >
> 
> Disclaimer: I have not tested it.
> 
> What I think, well I like that someone is working on this, and I like
> that you are using the wiki as "database", as with previous attempts
> part of the problem was that both a tool and a website needed to
> be developed simultaneously.
> 
> As for comments, see above.
> 
> Thanks & Regards,
> 
> Hans

Thanks,
Andre

PS: Sorry for the subject mismatch (RFC PATCH vs. PATCH RFC) :)

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

Re: [lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[Hans de Goede]

Hi,

On 01/15/2010 09:14 PM, Andre Prendel wrote:
> On Thu, Jan 14, 2010 at 11:35:33AM +0100, Hans de Goede wrote:
>> Hi Andre,
>
> Hi Hans,
>
> Thanks for your feedback :)
>
>> Thanks for working on this!
>>
>> On 01/13/2010 09:56 PM, Andre Prendel wrote:
>>> Hello Jean, Hans,
>>>
>>> a long time ago we've spoken about "DMI-based
>>> configuration". Unfortunately the last half year I only had a very
>>> reduced amount of time. But today I send my first proposal (patch) for
>>> this issue :)
>>>
>>> A few words...
>>>
>>> The tool is written in Python. I hope you can live with
>>> this although this is another language in the lm-sensors project. I like
>>> the object oriented modules of Python and IMHO Python should be
>>> installed on every machine in a default installation.
>>>
>>
>> Hmm, I don't mind the archive download and building tool being written
>> in python. But eventually there should also be a bash script which
>> can be run from the systems initscript which will automatically
>> find a config based on dmi and if found copy it to /etc/sensors-mb.conf
>> (which can then be included from the regular sensors.conf). I don't
>> think this part should be in python as on most systems none of the
>> other initscripts use python.
>
> What do you mean with this /etc/sensors-mb.conf? I don't know such a
> config file. My plan was to copy the file to the /etc/sensors.d
> directory. Configs in this directory overwrites the default
> sensors.conf config file.
>

Ah cool, yes that is pretty much the mechanism I had in mind, although
I believe the file should be renamed to motherboard.conf on copy-ing, see
below.

> I don't think we have to copy the file on every startup. It should be
> enough to do this while installing lm-sensors or if an update is
> available, right? But it's right, we need an trigger for the dmi-based
> configuration. This could be done from 'make install'.

Erm most people won't be doing make install, but will be installing
packages from a distro. Also think about cases like a livecd /
live usb stick, where the hardware must be discovered automatically
each boot, as it might be completely different.

An other scenario is the user swapping motherboard. So, just like
the rest of a modern Linux distributions dynamically discovers
all hardware each boot (swapping a video card or a motherboard
does not require making any configuration files now a days), lm_sensors
should dynamically discover and configure sensors (where possible).

So I disagree with "I don't think we have to copy the file on every startup."
this is also why the file should have a standard name like
/etc/sensors.d/auto-motherboard.conf

And I would even go as far as to say, that if no valid config was
found that file should be removed.

>
> Just a few words about my intention how to use the config-tool.
>
> The fetching and archive building part is only for config maintainers
> (e.g. you, Jean or me). If a new config is available or something
> changed a maintainer builds a new archive. This archive should be
> provided via lm-sensors.org.
>
> User can download the archive and use the config-tool the install
> it. We could improve the tool to inform the user for new updates and
> download the archive automatically.
>

Ok.

>>> What can you do with this tool?
>>>
>>> 1. Download config files from lm-sensors.org and build an archive
>>
>> Hmm, I see it currently has a hardcoded list of config files, it would
>> be good if it could discover the config files dynamically based on
>> what is available on lm-sensors.org
>
> That's right. We could maintain a file similar to the format generated
> by the wiki.
>
>    http://lm-sensors.org/wiki/Configurations
>
> Such a file is easy to parse and might contain only confirmed
> configurations. Or do you know a way to scan remote directories via
> HTTP?
>

No not really, you could parse the index page(s), but
having an easier to parse index file somewhere on lm-sensors.org is
fine.

>>> 2. Install this archive into the file system (the path is hard-coded
>>> so far)
>>
>> I think the path should be under /var/lib, as the contents can
>> change by running the same version of the tool again (if the
>> wiki is updated).
>
> It seems you're right again. The FHS says data in /usr/share must be
> purely static data. I will change the path.
>
>>> 3. List the vendors off the available configs
>>> 4. List the board configs of a vendor
>>> 5. Install a config by vendor and board name
>>> 6. Show your systems' DMI data
>>> 7. Search a config based on the DMI data and install them
>>
>> I see currently this assumes that the name as on the wiki (in
>> the url on the wiki), is the same as in the dmi info, this is
>> not necessarily true.
>
> The names don't have to exactly match. The lookup is case-insensitiv
> and the "wiki name" have to be part of the "dmi name". I did some test
> with the data Rudolf Marek sent in the first thread.
>
>    http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018982.html
>

Ok, the problem with this approach is that renaming wiki pages is not
trivial AFAIK. So if the wiki page name is poorly chosen (or atleast
chosen in such a way it does not match the DMI name), we are in trouble
I really believe we need a way to embed the DMI strings to search
for inside the configuration files.

>> There was a project similar to yours a
>> while ago, which added magic comments to the config files
>> to state for which dmi strings the config was valid. note
>> that one config could be valid for multiple boards.
>
> Yes, one config for multiple boards doesn't work at the
> moment. Probably we have to introduce some meta data for this
> issue. Maybe we could support single boards for now and add this
> feature later on!?
>

If the one config file multiple boards case was the only problem, sure,
but see above.

About all this also see:
http://sensors4mobo.eberian.com/

Which is something similar to what you were doing now, but which was
created as a project for private use and never got any bigger then that.

I'll forward you the announcement mail of this project.

Regards,

Hans


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

Re: [lm-sensors] [RFC PATCH 0/1] Add the sensors-config tool

[Andre Prendel]

On Sun, Jan 17, 2010 at 05:30:36PM +0100, Hans de Goede wrote:
> Hi,

Hello Hans,

> >
> >What do you mean with this /etc/sensors-mb.conf? I don't know such a
> >config file. My plan was to copy the file to the /etc/sensors.d
> >directory. Configs in this directory overwrites the default
> >sensors.conf config file.
> >
> 
> Ah cool, yes that is pretty much the mechanism I had in mind, although
> I believe the file should be renamed to motherboard.conf on copy-ing, see
> below.

Ok.

> >I don't think we have to copy the file on every startup. It should be
> >enough to do this while installing lm-sensors or if an update is
> >available, right? But it's right, we need an trigger for the dmi-based
> >configuration. This could be done from 'make install'.
> 
> Erm most people won't be doing make install, but will be installing
> packages from a distro. Also think about cases like a livecd /
> live usb stick, where the hardware must be discovered automatically
> each boot, as it might be completely different.
> 
> An other scenario is the user swapping motherboard. So, just like
> the rest of a modern Linux distributions dynamically discovers
> all hardware each boot (swapping a video card or a motherboard
> does not require making any configuration files now a days), lm_sensors
> should dynamically discover and configure sensors (where possible).
> 
> So I disagree with "I don't think we have to copy the file on every startup."
> this is also why the file should have a standard name like
> /etc/sensors.d/auto-motherboard.conf
> 
> And I would even go as far as to say, that if no valid config was
> found that file should be removed.

Ok, you've totally convinced me. So I will add (or extend the
existing?) initscript to do this discovery.

> >>>What can you do with this tool?
> >>>
> >>>1. Download config files from lm-sensors.org and build an archive
> >>
> >>Hmm, I see it currently has a hardcoded list of config files, it would
> >>be good if it could discover the config files dynamically based on
> >>what is available on lm-sensors.org
> >
> >That's right. We could maintain a file similar to the format generated
> >by the wiki.
> >
> >   http://lm-sensors.org/wiki/Configurations
> >
> >Such a file is easy to parse and might contain only confirmed
> >configurations. Or do you know a way to scan remote directories via
> >HTTP?
> >
> 
> No not really, you could parse the index page(s), but
> having an easier to parse index file somewhere on lm-sensors.org is
> fine.

Ok.

> >>>2. Install this archive into the file system (the path is hard-coded
> >>>so far)
> >>
> >>I think the path should be under /var/lib, as the contents can
> >>change by running the same version of the tool again (if the
> >>wiki is updated).
> >
> >>
> >>I see currently this assumes that the name as on the wiki (in
> >>the url on the wiki), is the same as in the dmi info, this is
> >>not necessarily true.
> >
> >The names don't have to exactly match. The lookup is case-insensitiv
> >and the "wiki name" have to be part of the "dmi name". I did some test
> >with the data Rudolf Marek sent in the first thread.
> >
> >   http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018982.html
> >
> 
> Ok, the problem with this approach is that renaming wiki pages is not
> trivial AFAIK. So if the wiki page name is poorly chosen (or atleast
> chosen in such a way it does not match the DMI name), we are in trouble
> I really believe we need a way to embed the DMI strings to search
> for inside the configuration files.

Ok, I will will read some more about the sensors4mobo project and then
we can discuss an approach.

> >>There was a project similar to yours a
> >>while ago, which added magic comments to the config files
> >>to state for which dmi strings the config was valid. note
> >>that one config could be valid for multiple boards.
> >
> >Yes, one config for multiple boards doesn't work at the
> >moment. Probably we have to introduce some meta data for this
> >issue. Maybe we could support single boards for now and add this
> >feature later on!?
> >
> 
> If the one config file multiple boards case was the only problem, sure,
> but see above.
> 
> About all this also see:
> http://sensors4mobo.eberian.com/
> 
> Which is something similar to what you were doing now, but which was
> created as a project for private use and never got any bigger then that.
> 
> I'll forward you the announcement mail of this project.

> Regards,
> 
> Hans
> 

Thanks,
Andre

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