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

[Hans de Goede <hdegoede@redhat.com>]

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