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

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

[Andre Prendel]

Hi Hans,

here is an updated version of the sensors-config tool.

Changes in v2:

Now the tool parses the configuration pages from lm-sensors.org to
determine the available config files.

Further I've introduced some metadata to the config files. For the
moment these are

# board_vendor: BOARDVENDOR
# board_name: BOARDNAME

The related files are located under /sys/class/dmi/id. board_name can
appear multiple times. So one config file can be used for several
motherboards.

The config files now will be installed under /var/lib and a matching
config will be copied as automobo.conf to /etc/sensors.d.

And I added a short script for use at startup. The script looks for an
suitable config and installs it otherwise it deletes an existing one.

So, this should address most of your comments from last email.

First question: What do you thing about the header keywords?

Maybe we could choose some of the available configs and add a
header. So you and can test the tool by yourself.

Second question: What should we use for the header data?

I'd suggest to only use a substring of the real dmi string. The
sensors-config tool don't need an exact match of the string.

For example

# board_vendor: Asus

matches for

ASUS
asus
Asus
ASUSTeK Computer INC.
...

Ok Hans, it's your turn.

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 v1 0/2] Add the sensors-config tool

[Hans de Goede]

Hi Andre,

On 02/19/2010 08:38 PM, Andre Prendel wrote:
> Hi Hans,
>
> here is an updated version of the sensors-config tool.
>
> Changes in v2:
>
> Now the tool parses the configuration pages from lm-sensors.org to
> determine the available config files.
>
> Further I've introduced some metadata to the config files. For the
> moment these are
>
> # board_vendor: BOARDVENDOR
> # board_name: BOARDNAME
>
> The related files are located under /sys/class/dmi/id. board_name can
> appear multiple times. So one config file can be used for several
> motherboards.
>
> The config files now will be installed under /var/lib and a matching
> config will be copied as automobo.conf to /etc/sensors.d.
>

Sounds good! Although I noticed that sensors-config.py still says:
config_dir = '/usr/local/share/sensors/conf

> And I added a short script for use at startup. The script looks for an
> suitable config and installs it otherwise it deletes an existing one.
>
> So, this should address most of your comments from last email.
>

Yes it does. Some remarks sofar (before answering your questions),
I would really like to see the initscript part of this not depend on
python. The last time this was discussed (in previous attempt to
come to a sensors-config tool), the idea was to (abuse) the database
a bit for this.

So for example my motherboard has:
board_vendor: "ASUSTeK Computer INC."
board_name: "M2N-SLI DELUXE"

/var/lib/sensors/conf could then contain a config file named:
"M2N-SLI Deluxe" (same name as on the wiki)

And then have a symlink (generated on the base of the metadata
in the config files):
"ASUSTeK Computer INC.-M2N-SLI DELUXE"

Then the whole dmi info -> config file matching can be done in a
simple sh script. This will not allow for the wildcard like
matching you have described, but in my experience that is not
really necessary. I've been doing a lot of dmi based quirks for
laptops, and I've seen only one case where the DMI data changed
on a BIOS update, and in that case we can simply have multiple
tags in the config file, what we could (and should) do is:
Strip all beginning and ending whitespace from the dmi info

This is easily doable in sh too.

> First question: What do you thing about the header keywords?
>

I think using the exact same names as under /sys/class/dmi/id
is a good idea.

> Maybe we could choose some of the available configs and add a
> header. So you and can test the tool by yourself.
>

Yes, I'll update them myself and give it a try. But before I do that
I wonder if I have the correct version of the script, above you write:
 > Now the tool parses the configuration pages from lm-sensors.org to
 > determine the available config files.

But in the sensors-config.py you attached I still see:

+configs = {
+    'ASRock' : ['AM2NF3-VSTA'],
+    'Abit' : ['AA8-DuraMAX', 'AA8XE-Fatal1ty', 'AI7', 'AN7',
+              'AN8-SLI', 'AV8', 'AX8', 'Aa7-Max', 'Ag7', 'KN9-Ultra',
+              'KV8-MAX3', 'Kv8Pro', 'VA-20'],
+    'Asus' : ['KFN4-DRE', 'M2N-SLI Deluxe'],
+    'DFI' : ['CFX3200-M2-G-infinity', 'Lanparty NF4 Expert',
+             'Lanparty UT 790FX'],
+    'Epox' : ['M1697', 'MF4-Ultra3'],
+    'Evga' : ['x58-SLI'],
+}

And this still gets used, did you perhaps accidentally send the old
version ?

> Second question: What should we use for the header data?
>

We should allow the following (for now):
board_vendor
board_name
board_version

sys_vendor
product_name
product_version

IOW, pretty much what you have already, and then if we
go the symlink route (I'm always open to suggestions to do
things differently), check for the following symlinks
(in order till one is found) :
$board_vendor-$board_name-$board_version
$sys_vendor-$product_name-$product_version
$board_vendor-$board_name
$sys_vendor-$product_name

> I'd suggest to only use a substring of the real dmi string. The
> sensors-config tool don't need an exact match of the string.
>
> For example
>
> # board_vendor: Asus
>
> matches for
>
> ASUS
> asus
> Asus
> ASUSTeK Computer INC.
> ...
>

That would work, but requires first reading all configuration
files into memory and extract the metadata before we can do the
matching, which as the database grows is going to become slow.

People won't like us reading say 200 files every startup, esp not
those people who try to get system startup time down to 5 seconds.

So I think a symlink like approach is better.

There is still one important piece missing here though, besides
automatically putting a config file in place, we also need to
make sure the necessary modules get loaded. IOW we need a metadata
keyword to specify which modules the config needs loaded (and with
which options if any), and then we need some init script to
load these modules (probably the same initscript as the
one doing the config file copying, or we could add the necessary
entries to /etc/sysconfig/lm_sensors from that script.

Regards,

Hans

p.s.

Note I have dmi data dumps for a lot of motherboards, ie for
all abituguru using motherboards. So once we have decided on
how to handle various things and on the metadata format, I can
update a lot of the config files in the wiki with the necessary
headers.

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

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

[Jean Delvare]

On Mon, 22 Feb 2010 10:04:17 +0100, Hans de Goede wrote:
> Hi Andre,
> 
> On 02/19/2010 08:38 PM, Andre Prendel wrote:
> > Hi Hans,
> >
> > here is an updated version of the sensors-config tool.
> >
> > Changes in v2:
> >
> > Now the tool parses the configuration pages from lm-sensors.org to
> > determine the available config files.
> >
> > Further I've introduced some metadata to the config files. For the
> > moment these are
> >
> > # board_vendor: BOARDVENDOR
> > # board_name: BOARDNAME
> >
> > The related files are located under /sys/class/dmi/id. board_name can
> > appear multiple times. So one config file can be used for several
> > motherboards.
> >
> > The config files now will be installed under /var/lib and a matching
> > config will be copied as automobo.conf to /etc/sensors.d.
> >
> 
> Sounds good! Although I noticed that sensors-config.py still says:
> config_dir = '/usr/local/share/sensors/conf
> 
> > And I added a short script for use at startup. The script looks for an
> > suitable config and installs it otherwise it deletes an existing one.
> >
> > So, this should address most of your comments from last email.
> >
> 
> Yes it does. Some remarks sofar (before answering your questions),
> I would really like to see the initscript part of this not depend on
> python. The last time this was discussed (in previous attempt to
> come to a sensors-config tool), the idea was to (abuse) the database
> a bit for this.
> 
> So for example my motherboard has:
> board_vendor: "ASUSTeK Computer INC."
> board_name: "M2N-SLI DELUXE"
> 
> /var/lib/sensors/conf could then contain a config file named:
> "M2N-SLI Deluxe" (same name as on the wiki)
> 
> And then have a symlink (generated on the base of the metadata
> in the config files):
> "ASUSTeK Computer INC.-M2N-SLI DELUXE"
> 
> Then the whole dmi info -> config file matching can be done in a
> simple sh script. This will not allow for the wildcard like
> matching you have described, but in my experience that is not
> really necessary. I've been doing a lot of dmi based quirks for
> laptops, and I've seen only one case where the DMI data changed
> on a BIOS update, and in that case we can simply have multiple
> tags in the config file, what we could (and should) do is:
> Strip all beginning and ending whitespace from the dmi info
> 
> This is easily doable in sh too.

If you really need to work on strings, this can be done in sh still,
either using the shell expansion capabilities, or by using sed. But see
below.

> > First question: What do you thing about the header keywords?
> >
> 
> I think using the exact same names as under /sys/class/dmi/id
> is a good idea.
> 
> > Maybe we could choose some of the available configs and add a
> > header. So you and can test the tool by yourself.
> >
> 
> Yes, I'll update them myself and give it a try. But before I do that
> I wonder if I have the correct version of the script, above you write:
>  > Now the tool parses the configuration pages from lm-sensors.org to
>  > determine the available config files.
> 
> But in the sensors-config.py you attached I still see:
> 
> +configs = {
> +    'ASRock' : ['AM2NF3-VSTA'],
> +    'Abit' : ['AA8-DuraMAX', 'AA8XE-Fatal1ty', 'AI7', 'AN7',
> +              'AN8-SLI', 'AV8', 'AX8', 'Aa7-Max', 'Ag7', 'KN9-Ultra',
> +              'KV8-MAX3', 'Kv8Pro', 'VA-20'],
> +    'Asus' : ['KFN4-DRE', 'M2N-SLI Deluxe'],
> +    'DFI' : ['CFX3200-M2-G-infinity', 'Lanparty NF4 Expert',
> +             'Lanparty UT 790FX'],
> +    'Epox' : ['M1697', 'MF4-Ultra3'],
> +    'Evga' : ['x58-SLI'],
> +}
> 
> And this still gets used, did you perhaps accidentally send the old
> version ?
> 
> > Second question: What should we use for the header data?
> >
> 
> We should allow the following (for now):
> board_vendor
> board_name
> board_version
> 
> sys_vendor
> product_name
> product_version
> 
> IOW, pretty much what you have already, and then if we
> go the symlink route (I'm always open to suggestions to do
> things differently), check for the following symlinks
> (in order till one is found) :
> $board_vendor-$board_name-$board_version
> $sys_vendor-$product_name-$product_version
> $board_vendor-$board_name
> $sys_vendor-$product_name
> 
> > I'd suggest to only use a substring of the real dmi string. The
> > sensors-config tool don't need an exact match of the string.
> >
> > For example
> >
> > # board_vendor: Asus
> >
> > matches for
> >
> > ASUS
> > asus
> > Asus
> > ASUSTeK Computer INC.
> > ...
> >

I would be very cautious with substring matching. Some vendors have
awfully short names (MSI, DFI or even HP or LG come to mind) and one of
these will inevitably be a substring of another vendor's name someday,
especially if you go for case-tolerant comparisons as suggested above.

> 
> That would work, but requires first reading all configuration
> files into memory and extract the metadata before we can do the
> matching, which as the database grows is going to become slow.
> 
> People won't like us reading say 200 files every startup, esp not
> those people who try to get system startup time down to 5 seconds.
> 
> So I think a symlink like approach is better.
> 
> There is still one important piece missing here though, besides
> automatically putting a config file in place, we also need to
> make sure the necessary modules get loaded. IOW we need a metadata
> keyword to specify which modules the config needs loaded (and with
> which options if any), and then we need some init script to
> load these modules (probably the same initscript as the
> one doing the config file copying, or we could add the necessary
> entries to /etc/sysconfig/lm_sensors from that script.

Beware that some device -> driver matching has changed over time, so
you might have to take the kernel version into account. If you think
this is overkill, then at least the driver needed for older kernel
versions should be mentioned in a free comment. Or maybe we can
introduce a specific syntax for fallback drivers (if the first driver
doesn't exist then the second is tried... should cover most cases but
maybe not all.)

> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> Note I have dmi data dumps for a lot of motherboards, ie for
> all abituguru using motherboards. So once we have decided on
> how to handle various things and on the metadata format, I can
> update a lot of the config files in the wiki with the necessary
> headers.

I have a lot of DMI data at hand, too.

-- 
Jean Delvare

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

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

[Hans de Goede]

Hi,

On 02/22/2010 10:52 AM, Jean Delvare wrote:

<snip>

>> There is still one important piece missing here though, besides
>> automatically putting a config file in place, we also need to
>> make sure the necessary modules get loaded. IOW we need a metadata
>> keyword to specify which modules the config needs loaded (and with
>> which options if any), and then we need some init script to
>> load these modules (probably the same initscript as the
>> one doing the config file copying, or we could add the necessary
>> entries to /etc/sysconfig/lm_sensors from that script.
>
> Beware that some device ->  driver matching has changed over time, so
> you might have to take the kernel version into account. If you think
> this is overkill, then at least the driver needed for older kernel
> versions should be mentioned in a free comment. Or maybe we can
> introduce a specific syntax for fallback drivers (if the first driver
> doesn't exist then the second is tried... should cover most cases but
> maybe not all.)
>

I think that this new autoconfig stuff will only (mostly) get used in newer
distro's with newer kernels. So I think we can just assume a recent kernel,
and put fallback drivers in a comment.

Still this warrants some thought, as in the future device driver names
may change once more.

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 v1 0/2] Add the sensors-config tool

[Andre Prendel]

On Mon, Feb 22, 2010 at 10:04:17AM +0100, Hans de Goede wrote:
> Hi Andre,
> 
> On 02/19/2010 08:38 PM, Andre Prendel wrote:
> >Hi Hans,
> >
> >here is an updated version of the sensors-config tool.
> >
> >Changes in v2:
> >
> >Now the tool parses the configuration pages from lm-sensors.org to
> >determine the available config files.
> >
> >Further I've introduced some metadata to the config files. For the
> >moment these are
> >
> ># board_vendor: BOARDVENDOR
> ># board_name: BOARDNAME
> >
> >The related files are located under /sys/class/dmi/id. board_name can
> >appear multiple times. So one config file can be used for several
> >motherboards.
> >
> >The config files now will be installed under /var/lib and a matching
> >config will be copied as automobo.conf to /etc/sensors.d.
> >
> 
> Sounds good! Although I noticed that sensors-config.py still says:
> config_dir = '/usr/local/share/sensors/conf

You're right. I've missed a "quilt refresh" before sending the patch,
sorry. I will send the correct patch right now.

> >And I added a short script for use at startup. The script looks for an
> >suitable config and installs it otherwise it deletes an existing one.
> >
> >So, this should address most of your comments from last email.
> >
> 
> Yes it does. Some remarks sofar (before answering your questions),
> I would really like to see the initscript part of this not depend on
> python. The last time this was discussed (in previous attempt to
> come to a sensors-config tool), the idea was to (abuse) the database
> a bit for this.
> 
> So for example my motherboard has:
> board_vendor: "ASUSTeK Computer INC."
> board_name: "M2N-SLI DELUXE"
> 
> /var/lib/sensors/conf could then contain a config file named:
> "M2N-SLI Deluxe" (same name as on the wiki)
> 
> And then have a symlink (generated on the base of the metadata
> in the config files):
> "ASUSTeK Computer INC.-M2N-SLI DELUXE"
> 
> Then the whole dmi info -> config file matching can be done in a
> simple sh script. This will not allow for the wildcard like
> matching you have described, but in my experience that is not
> really necessary. I've been doing a lot of dmi based quirks for
> laptops, and I've seen only one case where the DMI data changed
> on a BIOS update, and in that case we can simply have multiple
> tags in the config file, what we could (and should) do is:
> Strip all beginning and ending whitespace from the dmi info
> 
> This is easily doable in sh too.

Just a few words about my ideas for the sensors-config tool.

The tool consists of two parts.

Part 1: Fetch configs from lm-sensors.org and generate a directory layout
in the format:

  BOARD_VENDOR/BOARD_NAME e.g. ASUSTeK Computer INC./M2N-SLI DELUXE

Then this layout will be packed to an archive
(configuration.tar.gz). The archive is provided for downloading via
lm-sensors.org.

Part 2: An administration tool to (un)install the archive, list the
available configs (after installation), (un)install a config to/from
CONFIG_DIR and searching for a config using the DMI data.

That means, the tool should be more than a auto-configuration
tool. There should be an expert mode to do things manually. This
could be necessary if there is no matching config but the user wants
to test a similar config.

Nevertheless, we can do the auto-config stuff from a shell script.

At the moment the tool is looking under CONFIG_DIR for a directory
BOARD_VENDOR and into this directory for a file BOARD_NAME. This could
be done as well as from shell script. Yes, we can use sed for regex
matching but with the python way installing the automobo.conf is a
one-liner encapsulated inside the config tool.

> >First question: What do you thing about the header keywords?
> >
> 
> I think using the exact same names as under /sys/class/dmi/id
> is a good idea.

Ok, after Jean's email I think we should do so. But I don't like
spaces and some other special chars in filenames. Maybe we can replace
this chars by underscores. But then the matching stuff isn't so easy.

> >Maybe we could choose some of the available configs and add a
> >header. So you and can test the tool by yourself.
> >
> 
> Yes, I'll update them myself and give it a try. But before I do that
> I wonder if I have the correct version of the script, above you write:
> > Now the tool parses the configuration pages from lm-sensors.org to
> > determine the available config files.
> 
> But in the sensors-config.py you attached I still see:
> 
> +configs = {
> +    'ASRock' : ['AM2NF3-VSTA'],
> +    'Abit' : ['AA8-DuraMAX', 'AA8XE-Fatal1ty', 'AI7', 'AN7',
> +              'AN8-SLI', 'AV8', 'AX8', 'Aa7-Max', 'Ag7', 'KN9-Ultra',
> +              'KV8-MAX3', 'Kv8Pro', 'VA-20'],
> +    'Asus' : ['KFN4-DRE', 'M2N-SLI Deluxe'],
> +    'DFI' : ['CFX3200-M2-G-infinity', 'Lanparty NF4 Expert',
> +             'Lanparty UT 790FX'],
> +    'Epox' : ['M1697', 'MF4-Ultra3'],
> +    'Evga' : ['x58-SLI'],
> +}
> 
> And this still gets used, did you perhaps accidentally send the old
> version ?

See first comment.

> >Second question: What should we use for the header data?
> >
> 
> We should allow the following (for now):
> board_vendor
> board_name
> board_version
> 
> sys_vendor
> product_name
> product_version
> 
> IOW, pretty much what you have already, and then if we
> go the symlink route (I'm always open to suggestions to do
> things differently), check for the following symlinks
> (in order till one is found) :
> $board_vendor-$board_name-$board_version
> $sys_vendor-$product_name-$product_version
> $board_vendor-$board_name
> $sys_vendor-$product_name

Do we need the symlinks at all if we use the exact dmi vendor/board name?

> >I'd suggest to only use a substring of the real dmi string. The
> >sensors-config tool don't need an exact match of the string.
> >
> >For example
> >
> ># board_vendor: Asus
> >
> >matches for
> >
> >ASUS
> >asus
> >Asus
> >ASUSTeK Computer INC.
> >...
> >
> 
> That would work, but requires first reading all configuration
> files into memory and extract the metadata before we can do the
> matching, which as the database grows is going to become slow.

As mentioned above, the tool is looking for the directory BOARD_VENDOR
and a file BOARD_NAME into this directory. If found the file is copied
to /etc/sensors.d as automobo.conf. So if the directoy layout under
/var/lib once is made, the metadata isn't required.

> People won't like us reading say 200 files every startup, esp not
> those people who try to get system startup time down to 5 seconds.
> 
> So I think a symlink like approach is better.
> 
> There is still one important piece missing here though, besides
> automatically putting a config file in place, we also need to
> make sure the necessary modules get loaded. IOW we need a metadata
> keyword to specify which modules the config needs loaded (and with
> which options if any), and then we need some init script to
> load these modules (probably the same initscript as the
> one doing the config file copying, or we could add the necessary
> entries to /etc/sysconfig/lm_sensors from that script.

Ok, one by one :)

 
> Regards,
> 
> Hans

Thanks,
Andre

> p.s.
> 
> Note I have dmi data dumps for a lot of motherboards, ie for
> all abituguru using motherboards. So once we have decided on
> how to handle various things and on the metadata format, I can
> update a lot of the config files in the wiki with the necessary
> headers.

This is a good plan.

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

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

[Andre Prendel]

Add the sensors-config tool

This tool helps you to configure lm-sensors. Some of the features are:

* Download configs from lm-sensors.org and build an archive
* Install archives into file system
* List all the available configs
* Install configs by vendor and board name or automatically based on DMI data
* Show DMI data

---
 prog/detect/sensors-config.py |  237 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 237 insertions(+)

Index: prog/detect/sensors-config.py
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ prog/detect/sensors-config.py	2010-02-22 20:11:42.495418369 +0100
@@ -0,0 +1,304 @@
+#!/usr/bin/python
+
+import os
+import sys
+import optparse
+import urllib
+import re
+
+config_dir = '/var/lib/sensors/conf'
+config_install_dir = '/etc/sensors.d'
+dmi_dir = '/sys/class/dmi/id'
+sensors_url = 'http://www.lm-sensors.org'
+wiki_url = sensors_url + '/' + 'wiki'
+
+def get_vendor_list():
+    try:
+        dir = os.listdir(config_dir)
+        dir.sort()
+        return dir
+
+    except OSError:
+        print "Could not find configurations in " + config_dir
+        dir = []
+        return dir
+
+
+def list_vendors():
+    dir = get_vendor_list()
+    for name in dir:
+        print name
+
+
+def get_board_list(vendor):
+    try:
+        dir = os.listdir(config_dir + '/' + vendor)
+        dir.sort()
+
+        return dir
+
+    except:
+        print "Could not find a configuration for " + vendor
+        dir = []
+        return dir
+
+
+def list_boards(vendor):
+    dir = get_board_list(vendor)
+    for name in dir:
+        print name
+
+
+def clear_config_dir():
+    try:
+        dir = os.listdir(config_install_dir)
+        for name in dir:
+            os.remove(config_install_dir  + '/' + name)
+
+    except OSError:
+        return
+
+
+def install(src, dst = '', force = False):
+    if (force = False):
+        sys.stdout.write('This will delete older configurations. Do you want to proceed? [y/N]: ')
+        line = sys.stdin.readline()
+        if (line[0] = 'N' or line[0] = 'n' or line[0] = '\n'):
+            return
+
+    clear_config_dir()
+
+    if (dst = ''):
+        dst = src.split('/')[1]
+
+    os.system('cp %s %s' % (config_dir + '/' + src, '/etc/sensors.d/' + dst));
+
+
+def get_dmi_data():
+    dmi = {'sys_vendor': '',
+           'product_name': '',
+           'product_version': '',
+           'board_vendor': '',
+           'board_name': '',
+           'board_version': '',
+           'chassis_type': ''}
+
+    for key in dmi:
+        f = open(dmi_dir + '/' + key, 'r')
+        dmi[key] = f.read().rstrip('\n')
+        f.close()
+
+    return dmi
+
+
+def show_dmi():
+    dmi = get_dmi_data()
+    keys = dmi.keys()
+    keys.sort()
+    for key in keys:
+        print key + ': ' + dmi[key]
+
+
+def install_archive(archive):
+    if (os.path.exists(config_dir) = False):
+        os.makedirs(config_dir)
+    os.system("tar -xzf" + archive + " -C" + config_dir)
+
+
+def uninstall_archive():
+    if (os.path.exists(config_dir) = True):
+        os.system("rm -rf " + config_dir)
+
+
+def find_board(dmi, dir):
+    for name in dir:
+        if (dmi['board_name'].lower().find(name.lower()) != -1):
+            return name
+
+    return ''
+
+
+def find_vendor(vendor, board, force = False):
+    dmi = get_dmi_data()
+
+    if (vendor):
+        dmi['board_vendor'] = vendor
+
+    if (board):
+        dmi['board_name'] = board
+
+    dir = get_vendor_list()
+    board_dir = ''
+    for name in dir:
+        if (dmi['board_vendor'].lower().lower().find(name.lower()) != -1):
+            board_dir = get_board_list(name)
+            board = find_board(dmi, board_dir)
+            if (board != ''):
+                config = name + '/' + board
+                print 'Found a suitable configuration: ' + config
+
+                if (force = False):
+                    sys.stdout.write('Do you want to install this configuration? [y/N]: ')
+                    line = sys.stdin.readline()
+                    if (line[0] = 'Y' or line[0] = 'y'):
+                        install(config, 'automobo.conf');
+                else:
+                    install(config, 'automobo.conf', True);
+
+
+def get_config_names():
+    configs = []
+    url_vendors = urllib.urlopen(wiki_url + '/Configurations/Configurations')
+    data = url_vendors.read()
+    it  = re.finditer(r"<a href=\"/wiki/Configurations/.*?\">(.*?)</a>", data)
+    for m in it:
+        print m.group(1)
+        url_boards = urllib.urlopen(wiki_url + '/' + m.group(1))
+        board_data = url_boards.read()
+        print board_data
+        board_it  = re.finditer(r"<a href=\"/wiki/Configurations/.*?\">(Configurations/.*?)</a>", board_data)
+        for boards_m in board_it:
+            configs.append(boards_m.group(1))
+
+    return configs
+
+
+def parse_dmi(lines):
+    dmi = {'sys_vendor': '',
+           'product_name': '',
+           'product_version': '',
+           'board_vendor': '',
+           'board_name': [],
+           'board_version': '',
+           'chassis_type': ''}
+
+    for line in lines:
+        if line[0] = '#':
+            for key in dmi:
+                start = line.find(key + ':')
+                if start != -1:
+                    name = line.split(':')[1]
+                    if (key = 'board_name'):
+                        dmi[key].append(name.strip())
+                    else:
+                        dmi[key] = name.strip()
+
+    return dmi
+
+
+def strip_lines(lines):
+    start = end = 0;
+    for i in range(len(lines)):
+        if (lines[i].find('{{{') != -1):
+            start = i + 1
+
+        if (lines[i].find('}}}') != -1):
+            end = i - start
+
+    del lines[0:start]
+    del lines[end:]
+
+
+def create_file(dmi, lines):
+    if (dmi['board_vendor'] != '' and dmi['board_name'] != ''):
+        strip_lines(lines)
+        if (os.path.exists(dmi['board_vendor']) = False):
+            os.mkdir(dmi['board_vendor'])
+
+        for board in dmi['board_name']:
+            path = dmi['board_vendor'] + '/' + board
+            if (os.path.exists(path)):
+                print 'A config file for ' + dmi['board_vendor'] + '/' + \
+                board + ' already exists. Will be overwritten.'
+            f = open(path , 'w')
+            f.writelines(lines)
+            f.close()
+
+
+def fetch_configs():
+    configs = get_config_names()
+
+    for board in configs:
+        print 'Fetch config for ' + board
+        url = urllib.urlopen(wiki_url + '/' + board.replace(' ', '_')
+                             + '?format=txt')
+
+        lines = url.readlines()
+        dmi = parse_dmi(lines)
+        if (len(dmi['board_name']) > 0):
+            print dmi
+
+        create_file(dmi, lines);
+        url.close()
+
+    os.system('tar czf configuration.tar.gz *')
+
+
+def parse_cmdline():
+    parser = optparse.OptionParser()
+    parser.add_option('-l', '--list-vendors', dest='opt_list_vendors',
+                      action='store_true', help='lists all the vendors');
+    parser.add_option('-b', '--list-boards', dest='opt_list_boards',
+                      help='lists the boards for a given vendor')
+    parser.add_option('-i', '--install', dest='opt_install',
+                      help='installs the given configuration')
+    parser.add_option('-d', '--show-dmi', dest='opt_show_dmi',
+                      action='store_true', help='shows DMI data')
+    parser.add_option('-a', '--install-archive', dest='opt_install_archive',
+                      help='installs the given archive')
+    parser.add_option('-u', '--uninstall-archive',
+                      dest='opt_uninstall_archive', action='store_true',
+                      help='removes configurations from archive')
+    parser.add_option('-f', '--find-board', dest='opt_find_board',
+                      action='store_true',
+                      help='find a configuration based on DMI data')
+    parser.add_option('-B', '--dmi-board', dest='opt_dmi_board',
+                      help='overwrites DMI data for board')
+    parser.add_option('-V', '--dmi-vendor', dest='opt_dmi_vendor',
+                      help='overwrites DMI data for vendor')
+    parser.add_option('-t', '--fetch-configs', dest='opt_fetch_configs',
+                      action='store_true',
+                      help='fetches configurations from lm-sensors.org')
+    parser.add_option('-y', '--always-yes', dest='opt_always_yes',
+                      action='store_true',
+                      help='Answer all question with yes')
+
+    return parser.parse_args()
+
+
+# Main
+try:
+    (options, args) = parse_cmdline()
+
+    force = False
+    if (options.opt_always_yes):
+        force = True
+
+    if (options.opt_list_vendors):
+        list_vendors()
+
+    if (options.opt_list_boards):
+        list_boards(options.opt_list_boards)
+
+    if (options.opt_install):
+        install(options.opt_install, '', force)
+
+    if (options.opt_show_dmi):
+        show_dmi()
+
+    if (options.opt_install_archive):
+        install_archive(options.opt_install_archive)
+
+    if (options.opt_uninstall_archive):
+        uninstall_archive()
+
+    if (options.opt_find_board):
+        find_vendor(options.opt_dmi_vendor, options.opt_dmi_board, force)
+
+    if (options.opt_fetch_configs):
+        fetch_configs()
+
+except (OSError), e:
+    print e
+
+sys.exit(0)

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

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

[Andre Prendel]

On Mon, Feb 22, 2010 at 10:52:23AM +0100, Jean Delvare wrote:
> On Mon, 22 Feb 2010 10:04:17 +0100, Hans de Goede wrote:
> > Hi Andre,
> > 
> > On 02/19/2010 08:38 PM, Andre Prendel wrote:
> > > Hi Hans,
> > >
> > > here is an updated version of the sensors-config tool.
> > >
> > > Changes in v2:
> > >
> > > Now the tool parses the configuration pages from lm-sensors.org to
> > > determine the available config files.
> > >
> > > Further I've introduced some metadata to the config files. For the
> > > moment these are
> > >
> > > # board_vendor: BOARDVENDOR
> > > # board_name: BOARDNAME
> > >
> > > The related files are located under /sys/class/dmi/id. board_name can
> > > appear multiple times. So one config file can be used for several
> > > motherboards.
> > >
> > > The config files now will be installed under /var/lib and a matching
> > > config will be copied as automobo.conf to /etc/sensors.d.
> > >
> > 
> > Sounds good! Although I noticed that sensors-config.py still says:
> > config_dir = '/usr/local/share/sensors/conf
> > 
> > > And I added a short script for use at startup. The script looks for an
> > > suitable config and installs it otherwise it deletes an existing one.
> > >
> > > So, this should address most of your comments from last email.
> > >
> > 
> > Yes it does. Some remarks sofar (before answering your questions),
> > I would really like to see the initscript part of this not depend on
> > python. The last time this was discussed (in previous attempt to
> > come to a sensors-config tool), the idea was to (abuse) the database
> > a bit for this.
> > 
> > So for example my motherboard has:
> > board_vendor: "ASUSTeK Computer INC."
> > board_name: "M2N-SLI DELUXE"
> > 
> > /var/lib/sensors/conf could then contain a config file named:
> > "M2N-SLI Deluxe" (same name as on the wiki)
> > 
> > And then have a symlink (generated on the base of the metadata
> > in the config files):
> > "ASUSTeK Computer INC.-M2N-SLI DELUXE"
> > 
> > Then the whole dmi info -> config file matching can be done in a
> > simple sh script. This will not allow for the wildcard like
> > matching you have described, but in my experience that is not
> > really necessary. I've been doing a lot of dmi based quirks for
> > laptops, and I've seen only one case where the DMI data changed
> > on a BIOS update, and in that case we can simply have multiple
> > tags in the config file, what we could (and should) do is:
> > Strip all beginning and ending whitespace from the dmi info
> > 
> > This is easily doable in sh too.
> 
> If you really need to work on strings, this can be done in sh still,
> either using the shell expansion capabilities, or by using sed. But see
> below.
> 
> > > First question: What do you thing about the header keywords?
> > >
> > 
> > I think using the exact same names as under /sys/class/dmi/id
> > is a good idea.
> > 
> > > Maybe we could choose some of the available configs and add a
> > > header. So you and can test the tool by yourself.
> > >
> > 
> > Yes, I'll update them myself and give it a try. But before I do that
> > I wonder if I have the correct version of the script, above you write:
> >  > Now the tool parses the configuration pages from lm-sensors.org to
> >  > determine the available config files.
> > 
> > But in the sensors-config.py you attached I still see:
> > 
> > +configs = {
> > +    'ASRock' : ['AM2NF3-VSTA'],
> > +    'Abit' : ['AA8-DuraMAX', 'AA8XE-Fatal1ty', 'AI7', 'AN7',
> > +              'AN8-SLI', 'AV8', 'AX8', 'Aa7-Max', 'Ag7', 'KN9-Ultra',
> > +              'KV8-MAX3', 'Kv8Pro', 'VA-20'],
> > +    'Asus' : ['KFN4-DRE', 'M2N-SLI Deluxe'],
> > +    'DFI' : ['CFX3200-M2-G-infinity', 'Lanparty NF4 Expert',
> > +             'Lanparty UT 790FX'],
> > +    'Epox' : ['M1697', 'MF4-Ultra3'],
> > +    'Evga' : ['x58-SLI'],
> > +}
> > 
> > And this still gets used, did you perhaps accidentally send the old
> > version ?
> > 
> > > Second question: What should we use for the header data?
> > >
> > 
> > We should allow the following (for now):
> > board_vendor
> > board_name
> > board_version
> > 
> > sys_vendor
> > product_name
> > product_version
> > 
> > IOW, pretty much what you have already, and then if we
> > go the symlink route (I'm always open to suggestions to do
> > things differently), check for the following symlinks
> > (in order till one is found) :
> > $board_vendor-$board_name-$board_version
> > $sys_vendor-$product_name-$product_version
> > $board_vendor-$board_name
> > $sys_vendor-$product_name
> > 
> > > I'd suggest to only use a substring of the real dmi string. The
> > > sensors-config tool don't need an exact match of the string.
> > >
> > > For example
> > >
> > > # board_vendor: Asus
> > >
> > > matches for
> > >
> > > ASUS
> > > asus
> > > Asus
> > > ASUSTeK Computer INC.
> > > ...
> > >
> 
> I would be very cautious with substring matching. Some vendors have
> awfully short names (MSI, DFI or even HP or LG come to mind) and one of
> these will inevitably be a substring of another vendor's name someday,
> especially if you go for case-tolerant comparisons as suggested above.

You're totally right. See details in my reply to Hans' email.

> > 
> > That would work, but requires first reading all configuration
> > files into memory and extract the metadata before we can do the
> > matching, which as the database grows is going to become slow.
> > 
> > People won't like us reading say 200 files every startup, esp not
> > those people who try to get system startup time down to 5 seconds.
> > 
> > So I think a symlink like approach is better.
> > 
> > There is still one important piece missing here though, besides
> > automatically putting a config file in place, we also need to
> > make sure the necessary modules get loaded. IOW we need a metadata
> > keyword to specify which modules the config needs loaded (and with
> > which options if any), and then we need some init script to
> > load these modules (probably the same initscript as the
> > one doing the config file copying, or we could add the necessary
> > entries to /etc/sysconfig/lm_sensors from that script.
> 
> Beware that some device -> driver matching has changed over time, so
> you might have to take the kernel version into account. If you think
> this is overkill, then at least the driver needed for older kernel
> versions should be mentioned in a free comment. Or maybe we can
> introduce a specific syntax for fallback drivers (if the first driver
> doesn't exist then the second is tried... should cover most cases but
> maybe not all.)
> 
> > 
> > Regards,
> > 
> > Hans
> > 
> > p.s.
> > 
> > Note I have dmi data dumps for a lot of motherboards, ie for
> > all abituguru using motherboards. So once we have decided on
> > how to handle various things and on the metadata format, I can
> > update a lot of the config files in the wiki with the necessary
> > headers.
> 
> I have a lot of DMI data at hand, too.

Can you please send it to me?

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 v1 0/2] Add the sensors-config tool

[Jean Delvare]

On Mon, 22 Feb 2010 21:28:40 +0100, Andre Prendel wrote:
> On Mon, Feb 22, 2010 at 10:04:17AM +0100, Hans de Goede wrote:
> > I think using the exact same names as under /sys/class/dmi/id
> > is a good idea.
> 
> Ok, after Jean's email I think we should do so. But I don't like
> spaces and some other special chars in filenames. Maybe we can replace
> this chars by underscores. But then the matching stuff isn't so easy.

I don't like spaces either and I'm all for replacing them (and other
funky chars) by underscores. "tr" is your friend :) then sed to strip
the duplicates.

-- 
Jean Delvare

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

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

[Hans de Goede]

Hi,

On 02/22/2010 09:28 PM, Andre Prendel wrote:
> On Mon, Feb 22, 2010 at 10:04:17AM +0100, Hans de Goede wrote:
> The tool consists of two parts.
>
> Part 1: Fetch configs from lm-sensors.org and generate a directory layout
> in the format:
>
>    BOARD_VENDOR/BOARD_NAME e.g. ASUSTeK Computer INC./M2N-SLI DELUXE
>
> Then this layout will be packed to an archive
> (configuration.tar.gz). The archive is provided for downloading via
> lm-sensors.org.
>
> Part 2: An administration tool to (un)install the archive, list the
> available configs (after installation), (un)install a config to/from
> CONFIG_DIR and searching for a config using the DMI data.
>
> That means, the tool should be more than a auto-configuration
> tool. There should be an expert mode to do things manually. This
> could be necessary if there is no matching config but the user wants
> to test a similar config.
>
> Nevertheless, we can do the auto-config stuff from a shell script.
>

Ack, I also advocate for 2 parts, well 3 parts using your division, what
I envision is:

1) A python tool to create / manipulate / download / print configuration
    (archives).

2) A sysv style initscript which does the actual autoconfiguration on boot
    based on an installed, extracted database.

> At the moment the tool is looking under CONFIG_DIR for a directory
> BOARD_VENDOR and into this directory for a file BOARD_NAME. This could
> be done as well as from shell script. Yes, we can use sed for regex
> matching but with the python way installing the automobo.conf is a
> one-liner encapsulated inside the config tool.
>

I understand doing the installation of automobo.conf is easier from
python, but we will get lots of complaints if we try to get distro
to carry an initscript which depends on python as a default enabled
initscript.

>> IOW, pretty much what you have already, and then if we
>> go the symlink route (I'm always open to suggestions to do
>> things differently), check for the following symlinks
>> (in order till one is found) :
>> $board_vendor-$board_name-$board_version
>> $sys_vendor-$product_name-$product_version
>> $board_vendor-$board_name
>> $sys_vendor-$product_name
>
> Do we need the symlinks at all if we use the exact dmi vendor/board name?
>

Well, we can have one config file which is valid for multiple versions /
variants (think extra slots, extra onboard nic, whatever) boards, I
think we should not have multiple copies of that file then, using
a hierarchy with multiple levels is fine by me too, but then:
1) How will you deal with board / produty version (we are going to need
    these to uniquely identify some boards)
2) Are you going to handle having multiple board_name's in the same
    config file.

>>> I'd suggest to only use a substring of the real dmi string. The
>>> sensors-config tool don't need an exact match of the string.
>>>
>>> For example
>>>
>>> # board_vendor: Asus
>>>
>>> matches for
>>>
>>> ASUS
>>> asus
>>> Asus
>>> ASUSTeK Computer INC.
>>> ...
>>>
>>
>> That would work, but requires first reading all configuration
>> files into memory and extract the metadata before we can do the
>> matching, which as the database grows is going to become slow.
>
> As mentioned above, the tool is looking for the directory BOARD_VENDOR
> and a file BOARD_NAME into this directory. If found the file is copied
> to /etc/sensors.d as automobo.conf. So if the directoy layout under
> /var/lib once is made, the metadata isn't required.
>

Ack, but if we do the sub string matching, then the autoconf part of the
tool will need to build a database to search through to see if there are
any substring matches, if the strings are encoded in the filenames, then
the tool won't need to actually parse the files, but it will still need
to do readdir call(s) to get the names from the filename, where as with
a 1 on 1 relation (be it with or without translations for spaces), a single
stat call suffices to see if there is a config file.

About the translation of spaces to _ in the filenames, I'm not in favor
of this. filenames with spaces will work fine if the sh script is
properly written and I would like to avoid invoking numerous sub processes
in the sysv shell script if possible. OTOH if this becomes too much of a
pain we can go the replace whitespace by _ route, because it is not
going to be that much of a penalty.

>> People won't like us reading say 200 files every startup, esp not
>> those people who try to get system startup time down to 5 seconds.
>>
>> So I think a symlink like approach is better.
>>
>> There is still one important piece missing here though, besides
>> automatically putting a config file in place, we also need to
>> make sure the necessary modules get loaded. IOW we need a metadata
>> keyword to specify which modules the config needs loaded (and with
>> which options if any), and then we need some init script to
>> load these modules (probably the same initscript as the
>> one doing the config file copying, or we could add the necessary
>> entries to /etc/sysconfig/lm_sensors from that script.
>
> Ok, one by one :)
>

hehe.

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 v1 0/2] Add the sensors-config tool

[VDR User]

On Mon, Feb 22, 2010 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> At the moment the tool is looking under CONFIG_DIR for a directory
>> BOARD_VENDOR and into this directory for a file BOARD_NAME. This could
>> be done as well as from shell script. Yes, we can use sed for regex
>> matching but with the python way installing the automobo.conf is a
>> one-liner encapsulated inside the config tool.
>
> I understand doing the installation of automobo.conf is easier from
> python, but we will get lots of complaints if we try to get distro
> to carry an initscript which depends on python as a default enabled
> initscript.

You are right, you can expect a LOT of complaints if you make an
initscript python-dependent.  Especially when there is no good reason
to do so.  Being able to do it in Python with a one-liner is not even
close to a good reason!

> 1) How will you deal with board / produty version (we are going to need
>   these to uniquely identify some boards)

Not sure why this would be an issue..?

> 2) Are you going to handle having multiple board_name's in the same
>   config file.

Why would this be any problem at all?

> About the translation of spaces to _ in the filenames, I'm not in favor
> of this. filenames with spaces will work fine if the sh script is
> properly written and I would like to avoid invoking numerous sub processes
> in the sysv shell script if possible. OTOH if this becomes too much of a
> pain we can go the replace whitespace by _ route, because it is not
> going to be that much of a penalty.

As you've already pointed out, filenames with spaces is not problem
when the shell script is properly written.  So why bother with any
substitution when it's not even necessary?

Best regards.

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

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

[Hans de Goede]

Hi,

On 02/22/2010 11:40 PM, VDR User wrote:
> On Mon, Feb 22, 2010 at 1:26 PM, Hans de Goede<hdegoede@redhat.com>  wrote:
>>> At the moment the tool is looking under CONFIG_DIR for a directory
>>> BOARD_VENDOR and into this directory for a file BOARD_NAME. This could
>>> be done as well as from shell script. Yes, we can use sed for regex
>>> matching but with the python way installing the automobo.conf is a
>>> one-liner encapsulated inside the config tool.
>>
>> I understand doing the installation of automobo.conf is easier from
>> python, but we will get lots of complaints if we try to get distro
>> to carry an initscript which depends on python as a default enabled
>> initscript.
>
> You are right, you can expect a LOT of complaints if you make an
> initscript python-dependent.  Especially when there is no good reason
> to do so.  Being able to do it in Python with a one-liner is not even
> close to a good reason!
>
>> 1) How will you deal with board / produty version (we are going to need
>>    these to uniquely identify some boards)
>
> Not sure why this would be an issue..?
>

This would be an issue when using:
<some-path>/board_vendor/board_name

To locate the correct config file, as there is no version present in that scheme

>> 2) Are you going to handle having multiple board_name's in the same
>>    config file.
>
> Why would this be any problem at all?
>


The same, this would mean having multiple copies of the same file when using
the above dir layout.

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 v1 0/2] Add the sensors-config tool

[VDR User]

On Tue, Feb 23, 2010 at 12:20 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> 1) How will you deal with board / produty version (we are going to need
>>>   these to uniquely identify some boards)
>>
>> Not sure why this would be an issue..?
>
> This would be an issue when using:
> <some-path>/board_vendor/board_name
>
> To locate the correct config file, as there is no version present in that
> scheme
>
>>> 2) Are you going to handle having multiple board_name's in the same
>>>   config file.
>>
>> Why would this be any problem at all?
>
> The same, this would mean having multiple copies of the same file when using
> the above dir layout.

Instead of creating a big dir tree, why not just put all the different
config files (which should be named using common sense) into one dir
and maintain a text file which points the
vendor/model/version/whatever_else to the correct file?  Then you can
just grep what you're looking for.  I'm a fan of not making things
harder then they need to be, especially when it can be so simple. ;)

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

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

[Andre Prendel]

On Mon, Feb 22, 2010 at 10:26:47PM +0100, Hans de Goede wrote:
> Hi,

Hello,

> On 02/22/2010 09:28 PM, Andre Prendel wrote:

> >Nevertheless, we can do the auto-config stuff from a shell script.
> >
> 
> Ack, I also advocate for 2 parts, well 3 parts using your division, what
> I envision is:
> 
> 1) A python tool to create / manipulate / download / print configuration
>    (archives).
> 
> 2) A sysv style initscript which does the actual autoconfiguration on boot
>    based on an installed, extracted database.

Ok, that's fine with me.

> >At the moment the tool is looking under CONFIG_DIR for a directory
> >BOARD_VENDOR and into this directory for a file BOARD_NAME. This could
> >be done as well as from shell script. Yes, we can use sed for regex
> >matching but with the python way installing the automobo.conf is a
> >one-liner encapsulated inside the config tool.
> >
> 
> I understand doing the installation of automobo.conf is easier from
> python, but we will get lots of complaints if we try to get distro
> to carry an initscript which depends on python as a default enabled
> initscript.

Now I'm convinced we shouldn't have a python dependency in the initscript.

> >>IOW, pretty much what you have already, and then if we
> >>go the symlink route (I'm always open to suggestions to do
> >>things differently), check for the following symlinks
> >>(in order till one is found) :
> >>$board_vendor-$board_name-$board_version
> >>$sys_vendor-$product_name-$product_version
> >>$board_vendor-$board_name
> >>$sys_vendor-$product_name
> >
> >Do we need the symlinks at all if we use the exact dmi vendor/board name?
> >
> 
> Well, we can have one config file which is valid for multiple versions /
> variants (think extra slots, extra onboard nic, whatever) boards, I
> think we should not have multiple copies of that file then, using
> a hierarchy with multiple levels is fine by me too, but then:
> 1) How will you deal with board / produty version (we are going to need
>    these to uniquely identify some boards)
> 2) Are you going to handle having multiple board_name's in the same
>    config file.

I like the multiple level directory layout because printing all
vendors or all boards for a specific vendor is a simple directory
listing (see -l and -b options). BTW I like a clean layout.

Of course we can encode the version by another directory level or in
the board name, couldn't we?

To avoid multiple files for the same board we could place the symlinks
into root directory. This layout would also avoid the problem of
identical board names of different vendors.

> >>>I'd suggest to only use a substring of the real dmi string. The
> >>>sensors-config tool don't need an exact match of the string.
> >>>
> >>>For example
> >>>
> >>># board_vendor: Asus
> >>>
> >>>matches for
> >>>
> >>>ASUS
> >>>asus
> >>>Asus
> >>>ASUSTeK Computer INC.
> >>>...
> >>>
> >>
> >>That would work, but requires first reading all configuration
> >>files into memory and extract the metadata before we can do the
> >>matching, which as the database grows is going to become slow.
> >
> >As mentioned above, the tool is looking for the directory BOARD_VENDOR
> >and a file BOARD_NAME into this directory. If found the file is copied
> >to /etc/sensors.d as automobo.conf. So if the directoy layout under
> >/var/lib once is made, the metadata isn't required.
> >
> 
> Ack, but if we do the sub string matching, then the autoconf part of the
> tool will need to build a database to search through to see if there are
> any substring matches, if the strings are encoded in the filenames, then
> the tool won't need to actually parse the files, but it will still need
> to do readdir call(s) to get the names from the filename, where as with
> a 1 on 1 relation (be it with or without translations for spaces), a single
> stat call suffices to see if there is a config file.

Ok, sub string matching is obsolete.

> About the translation of spaces to _ in the filenames, I'm not in favor
> of this. filenames with spaces will work fine if the sh script is
> properly written and I would like to avoid invoking numerous sub processes
> in the sysv shell script if possible. OTOH if this becomes too much of a
> pain we can go the replace whitespace by _ route, because it is not
> going to be that much of a penalty.
> 

Regards,
Andre

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

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

[Hans de Goede]

Hi,

On 02/23/2010 09:35 PM, Andre Prendel wrote:
> On Mon, Feb 22, 2010 at 10:26:47PM +0100, Hans de Goede wrote:
>> Hi,
>
> Hello,
>
>> On 02/22/2010 09:28 PM, Andre Prendel wrote:
>
>> Well, we can have one config file which is valid for multiple versions /
>> variants (think extra slots, extra onboard nic, whatever) boards, I
>> think we should not have multiple copies of that file then, using
>> a hierarchy with multiple levels is fine by me too, but then:
 >>
>> 1) How will you deal with board / produty version (we are going to need
>>     these to uniquely identify some boards)
>> 2) Are you going to handle having multiple board_name's in the same
>>     config file.
>
> I like the multiple level directory layout because printing all
> vendors or all boards for a specific vendor is a simple directory
> listing (see -l and -b options). BTW I like a clean layout.
>
> Of course we can encode the version by another directory level or in
> the board name, couldn't we?
>
> To avoid multiple files for the same board we could place the symlinks
> into root directory. This layout would also avoid the problem of
> identical board names of different vendors.
>

Having multiple directory levels is fine by me. I was merely
pointing out that there are some issues with that approach.

Thinking of this another possible issue is that vendors don't
always use the same vendor string in the DMI data.

So I think that the following would be a good solution:

1 dir per vendor, with vendor board configs in there, just like
the wiki.

symlinks in the base dir following the symlink structure I suggested
earlier.

This way we get the best of both worlds I think.

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 v1 0/2] Add the sensors-config tool

[Andre Prendel]

On Wed, Feb 24, 2010 at 02:58:56PM +0100, Hans de Goede wrote:
> Hi,
> 
> Having multiple directory levels is fine by me. I was merely
> pointing out that there are some issues with that approach.
> 
> Thinking of this another possible issue is that vendors don't
> always use the same vendor string in the DMI data.
> 
> So I think that the following would be a good solution:
> 
> 1 dir per vendor, with vendor board configs in there, just like
> the wiki.
> 
> symlinks in the base dir following the symlink structure I suggested
> earlier.
> 
> This way we get the best of both worlds I think.

Sounds good. I will take some time to revise the tool and come with an
updated version.

> Regards,
> 
> Hans

Thanks,
Andre

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