Add the sensors-config tool

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.

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

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.
...

Hi Andre,

Quoted 15 lines · 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

Quoted 7 lines

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

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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:

Quoted 2 lines

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:

(quoted diff) +11 -0

+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 ?

Quoted 2 lines

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

Quoted 15 lines

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.

Quoted 8 lines

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.)

Hi Andre,

Quoted 19 lines · 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.

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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:

Quoted 2 lines

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:

(quoted diff) +11 -0

+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 ?

Quoted 2 lines

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

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 61 lines · Hans de Goede

Hi Andre,

Quoted 15 lines · 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

Quoted 7 lines

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

Quoted 5 lines

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

Quoted 1 line

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.

Quoted 44 lines

Quoted 2 lines

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.

Quoted 3 lines

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:

Quoted 2 lines

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:

(quoted diff) +11 -0

+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 ?

Quoted 2 lines

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

Quoted 24 lines

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

Quoted 15 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

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.)

Quoted 7 lines

Regards,

Hans

p.s.

Quoted 5 lines

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.

Quoted 2 lines · Hans de Goede

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.

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.

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.

Quoted 8 lines

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?

Quoted 16 lines

Quoted 15 lines

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.
...

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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 :)

Quoted 5 lines

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.

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.

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.

Quoted 10 lines · Hans de Goede

Quoted 5 lines

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!

Quoted 2 lines

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..?

Quoted 2 lines

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

Why would this be any problem at all?

Quoted 4 lines

Quoted 2 lines

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

Quoted 4 lines

Quoted 2 lines

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.

Hi,

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 11 lines

Quoted 8 lines

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.

Quoted 16 lines

Quoted 16 lines

Quoted 15 lines

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.
...

Quoted 9 lines

Quoted 3 lines

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.

Quoted 1 line · Hans de Goede

Hi,

Hello,

Quoted 11 lines · Andre Prendel

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.

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.

Regards,

Hans