[lm-sensors] Motherboard-specific configurations (sensors4mobo)

[lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ed Lucas]

Dear Lm-sensors team,
    Back in 2005 the company I was working for needed consistent access 
to sensor data from a range of motherboards (we were building 
Managed-NAS systems), so we created motherboard-specific sensors.conf 
files and a tool to install and query them. I have now been given 
permission to update and release this software under the GPL.

I have placed it all online at:
    http://sensors4mobo.eberian.com

Online Query Tool:
    http://sensors4mobo.eberian.com/lookup/

Sample sensors.conf file:
    http://sensors4mobo.eberian.com/lookup/mobolibrary/EPIA.conf


We aimed to tackle the following:

* We were very happy with lm-sensors itself, but we found the output of 
"/usr/bin/sensors" hard to parse reliably because of the variable labels 
and fixed-width formatting. Instead, we now take the raw 
"/usr/bin/sensors -u" output and massage it into a consistent CSV format 
with extra data from an overlay file.

* We needed an automated install for our systems. Understandably, 
sensors-detect won't do this because it could kill the motherboard. We 
felt it would be cleaner to work top-down using the output from 
dmidecode to identify the motherboard and use a script to automatically 
pick the matching sensors.conf file. We achieved this by adding keywords 
and parameters in the comments within the sensors.conf files which this 
script detects and uses to match against the dmidecode output.  The 
keywords allow the correct matching to the appropriate sensors.conf file 
and can also include modprobe information to be added to /etc/modules.  
An example of this is shown in the EPIA.conf file referenced above. 

* We wanted to standardise the terms used, so that it would be easier to 
grep/understand what each sensor was being used to report. Initially, we 
used a custom (and somewhat arcane) labelling convention that embedded 
the type of sensor (fan,temperature,voltage) and the role in the label. 
This has been replaced with a script that massages the output of 
"sensors -u" and allows us to add extra overlay information. Through the 
overlay we can add a (fixed) set of tags to describe the function of the 
sensor - these can then be set on a case-by-case basis as well as a 
human-readable comment field.


Overall, the idea of sensors4mobo is to act as an overlay to 
sensors/dmidecode to add motherboard/installation-specific information 
that is outside the current scope of the lm-sensors project.  It also 
allows a motherboard to be matched against an exact sensors.conf file 
and removes the potential for error when a sensor chip may be used in 
different ways on different motherboards (e.g. it may have a different 
external resistor divider network).

Is this of interest to anyone on the list? and do you have any 
questions/suggestions?

If you have any motherboard-specific sensors.conf files that you would 
like to add, please just send them to me along with either the output of 
"sensors4mobo_lookup --dump" or dmidecode and I will get on it.

Since developing this, I have become aware of the sconfig tool created 
during Google SoC 2006. It is interesting and I hope that we can find 
some common ground around the sensors.conf files themselves, but I think 
the two projects are sufficiently different in style and goal to merit 
their existence.

Thanks and best wishes,
    Ed Lucas

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Ivo, Ed,

Ed, please fix your Reply-To.

On Tue, 27 Mar 2007 08:03:58 +0200, Ivo Manca wrote:
> We (three students from the Netherlands) are running quite a similar project 
> right now: adding DMI support to sensors-detect, which tries to find a match 
> with a local-database, then extracts the corresponding configuration. It 
> sounds quite like the project you made.
> 
> I don't have time to look into the software you made right now, but I will 
> tonight. But it sounds like it is at least "very useful".
> 
> I wonder what Jean (and ofcourse: everyone else) will think about it,

Jean didn't have enough time to look into one project, he hardly has
more time looking into two :( So I'll leave it up to you (Ivo and Ed)
and Hans to pick the best ideas and come up with one common solution. I
really don't think we want to have two or more projects doing the same
thing.

As Hans underlined earlier, getting the dynamic chips support in
libsensors first should address a number of problems.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ivo Manca]

Hey Jean,

Sorry if it sounded like "Jean will just make enough time available to fix 
it all", I didn't mean that :)

Anyway, I agree that having more than one project is everything but 
desireble. Since we started to add these functions to sensors-detect anyway, 
I think it is best if we just continue with it and take the best practices 
from the other projects. I think it is also the best if this functionality 
is added to the sensors-detect script, instead of (multiple?) other scripts.

So, thanks for your time, and you'll be hearing from us every now and then,

Ivo
----- Original Message ----- 
From: "Jean Delvare" <khali@linux-fr.org>
To: "Ivo Manca" <pinkel@gmail.com>
Cc: "Ed Lucas" <ejl@eberian.com>; <lm-sensors@lm-sensors.org>; "Weg, G. van 
der" <g.vanderweg@student.hhs.nl>; <J.W.R.deGoede@hhs.nl>
Sent: Tuesday 27 March 2007 17:39
Subject: Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)


> Hi Ivo, Ed,
>
> Ed, please fix your Reply-To.
>
> On Tue, 27 Mar 2007 08:03:58 +0200, Ivo Manca wrote:
>> We (three students from the Netherlands) are running quite a similar 
>> project
>> right now: adding DMI support to sensors-detect, which tries to find a 
>> match
>> with a local-database, then extracts the corresponding configuration. It
>> sounds quite like the project you made.
>>
>> I don't have time to look into the software you made right now, but I 
>> will
>> tonight. But it sounds like it is at least "very useful".
>>
>> I wonder what Jean (and ofcourse: everyone else) will think about it,
>
> Jean didn't have enough time to look into one project, he hardly has
> more time looking into two :( So I'll leave it up to you (Ivo and Ed)
> and Hans to pick the best ideas and come up with one common solution. I
> really don't think we want to have two or more projects doing the same
> thing.
>
> As Hans underlined earlier, getting the dynamic chips support in
> libsensors first should address a number of problems.
>
> Thanks,
> -- 
> Jean Delvare 


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ed Lucas]

Hi Folks,
(Jean: Apologies for the Reply-to mix-up. I hope I have it fixed now?)

Ivo Manca wrote:
> Anyway, I agree that having more than one project is everything but 
> desireble. 
Hmm, playing devils advocate here, I don't know if the projects have 
quite the same goals. If not, it might be just as desirable to find 
areas of compatibility.

Ah, I have just found Ivo's thread started on the 22nd February, and 
read the Project Plan (hence the delay in replying - sorry!) . That 
makes things much clearer. The projects are very similar, but I *think* 
sensors4mobo is unique in aiming to add local data overlays?

> Since we started to add these functions to sensors-detect anyway, I 
> think it is best if we just continue with it and take the best 
> practices from the other projects. I think it is also the best if this 
> functionality is added to the sensors-detect script, instead of 
> (multiple?) other scripts.
I think you are right that it makes sense to add the functionality to 
sensors-detect, and working directly under Hans, you are certainly 
ideally placed to do this.

I see from your plan that your Secondary Goal is to build a database of 
sensors.conf files (with a web interface), but that hosting and 
maintenance are outside your scope. If you don't already have this 
sorted through lm-sensors.org, I would be happy to offer ongoing hosting 
and maintenance, and can give you access rights on 
sensors4mobo.eberian.com.

Would you be interested in using the sensors4mobo sensors.conf 
annotation (or a derivative) to add dmidecode and modprobe data to the 
files? And/or would you be interested in using the web api (or a 
derivative) as an interface to the library?

http://sensors4mobo.eberian.com/docs/sensors_conf

    I think it is best to embed information in the sensors.conf rather 
than to use a database. It is backward compatible, and makes each 
configuration a tidy unit - much easier to copy/duplicate/update than a 
database. I know it is slower and more limited than a db in terms of 
querying, but I have just run a test and sensors4mobo.php parsed 1000 
files in under 0.8 seconds on a 1.3Ghz Sempron. We probably don't need 
to optimise just yet? I think it is also easier this way if users want 
to create their own mirror sites with customised/experimental 
sensors.conf files.


http://sensors4mobo.eberian.com/lookup/

    In addition to the query engine itself, this page also has notes on 
how the REST-ish interface works. It currently takes the 17 tags 
specified by dmidecode --strings, but of course it could be restricted 
to the subset your research has focused on.


Irrespective of technical factors, and beyond the scope of your project, 
the broader campaign will stand or fail on whether it can get a critical 
mass of sensor.conf files. The sooner we can start the ball rolling on 
this, the better, and the more data-points you will be able to test 
against. The sensors4mobo scripts (or derivatives!) could provide a way 
for current users to get involved before your code gets integrated and 
released.

I appreciate that you are doing this as a university project, and I 
don't want to undermine, impinge, or force an unwanted direction on your 
work, but I am keen to assist if there is a way to integrate into the 
bigger picture.

Best regards,
    Ed



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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ivo Manca]

Hey Ed,

I can't seem to find a way to download your software from the site. Is there 
simply no link, or am I just too tired to see it? :)

> Hmm, playing devils advocate here, I don't know if the projects have quite 
> the same goals. If not, it might be just as desirable to find areas of 
> compatibility.
>
> Ah, I have just found Ivo's thread started on the 22nd February, and read 
> the Project Plan (hence the delay in replying - sorry!) . That makes 
> things much clearer. The projects are very similar, but I *think* 
> sensors4mobo is unique in aiming to add local data overlays?

Nah, not trying to play the devil's advocate, just saying what I think is 
the easiest for the users ;). If all can be up-and-running by just using the 
lm-sensors package, why install anything else?

About the overlay: I think it is indeed something completely different than 
our project, so I think I can't say anything about that, sorry.

> I see from your plan that your Secondary Goal is to build a database of 
> sensors.conf files (with a web interface), but that hosting and 
> maintenance are outside your scope. If you don't already have this sorted 
> through lm-sensors.org, I would be happy to offer ongoing hosting and 
> maintenance, and can give you access rights on sensors4mobo.eberian.com.

We haven't had contact about whether or not this project can be hosted on 
lm-senors.org, yet. Imho, I prefer having everything on a same place, so if 
we can actually host it on lm-sensors.org, I will go for that. If not, 
having a link on lm-sensors.org, and hosting it somewhere else, is also 
good. The reason we haven't asked about hosting yet, is mainly because we're 
not sure in what language we want to script the website, but I think it will 
be PHP. Jasper and Gijs (the other two project members) are looking into 
that right now.

Anyway, thanks a lot for the offer!

> Would you be interested in using the sensors4mobo sensors.conf annotation 
> (or a derivative) to add dmidecode and modprobe data to the files?

Actually, I do not really care about how the sensors.conf is interpreted. I 
just looked at yours, and having the modprobes in it seems like a good idea 
to me. However, I am everything but an expert in this field, so again, I 
think i can't be of much help.

Our project only aims at the detection, and that's it. We've already set up 
a (sample) database layout, which will have three tables. One table with the 
dmi-strings, configuration file and a flag whether it's working, not working 
or untested, one table with all the available modules, and one table that 
links the modules to the configuration and can add parameters to it.

This way, it doesn't really matter what kind of configuration will be stored 
within it, as long as they're compatible.

> And/or would you be interested in using the web api (or a derivative) as 
> an interface to the library?

The web API itself seems to look quite okay, however, I don't agree with one 
thing:

As I understand it, when the user wants to find a match, he/she sends the 
dmi-strings to the website, which might give some privacy issues (tbh: I 
don't care myself ;p). And, the most important thing: when the client's 
internetconnection is down, or when the website is down, it can't be used 
anymore. Correct me if I'm wrong.

> http://sensors4mobo.eberian.com/docs/sensors_conf
>
>    I think it is best to embed information in the sensors.conf rather than 
> to use a database. It is backward compatible, and makes each configuration 
> a tidy unit - much easier to copy/duplicate/update than a database. I know 
> it is slower and more limited than a db in terms of querying, but I have 
> just run a test and sensors4mobo.php parsed 1000 files in under 0.8 
> seconds on a 1.3Ghz Sempron. We probably don't need to optimise just yet? 
> I think it is also easier this way if users want to create their own 
> mirror sites with customised/experimental sensors.conf files.

Having a database is also backwards compatible ;). The user can still 
decided whether or not to use the dmi-comparison and everything but the 
sensors-detect is left untouched.
About making it less easy to copy/duplicate/update using plaintext files: 
normally I would agree, however, we are are planning on using SQLite as 
backend. This way, the database will be a single file, and easily 
distrubuted.

http://www.sqlite.org/

Having a flag "unsure" (or something similar) to the configuration, makes it 
possible for users to upload their expirimental sensors.conf files.

>
> http://sensors4mobo.eberian.com/lookup/
>
>    In addition to the query engine itself, this page also has notes on how 
> the REST-ish interface works. It currently takes the 17 tags specified by 
> dmidecode --strings, but of course it could be restricted to the subset 
> your research has focused on.

We were thinking about using the following:
system-manufacturer
system-product-name
system-version
system-serial-number
baseboard-manufacturer
baseboard-product-name
baseboard-version

It seems like these 6 fields covers all motherboards. Sending/storing the 
serial number might also be a privacy issue.

>
> Irrespective of technical factors, and beyond the scope of your project, 
> the broader campaign will stand or fail on whether it can get a critical 
> mass of sensor.conf files. The sooner we can start the ball rolling on 
> this, the better, and the more data-points you will be able to test 
> against. The sensors4mobo scripts (or derivatives!) could provide a way 
> for current users to get involved before your code gets integrated and 
> released.

I totally agree with that. I think the ball gets to roll quicker if it's 
intergrated though ;).
Anyway, I do encourage everyone to use your sensors4mobo scripts and give us 
as much feedback as possible. That way, we can make a best effort as 
possible.

Oh, and if (in the end) we decide to do it my way, the configs aren't 
uploaded for nothing either! I think it's quite easy to convert them into 
our database ;)

> I appreciate that you are doing this as a university project, and I don't 
> want to undermine, impinge, or force an unwanted direction on your work, 
> but I am keen to assist if there is a way to integrate into the bigger 
> picture.

I don't feel undermined or anything, don't worry ;). However, at the moment, 
I think our solution is more deserible.

I don't want to make you feel like you wasted your time on this though or 
like I'm discarding all the work you did as rubbish. I'm just trying to 
share my vision, and hey, I'm not the one in charge ;)
Feel free to fill me in or share your opinion,

Ivo 


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Hans de Goede]

Ivo Manca wrote:
> Hey Ed,
> 
>> I looked at sqlite when developing sensors4mobo but many ISPs do not 
>> include it and I did not want to add any dependencies that would limit 
>> usage or make installation harder.
> 

<lots of explanation by Ivo about sqlite plans snipped>

Actually I have been thinking about using the annotating of sensors.conf file 
myself in the past, but I thought sqlite would be easier to use, esp. on the 
web-side. Since with sensors4mobo we kinda get the web-side for free, and I 
also _really_ like the idea of the database being a dir of textfiles with one 
file per motherboard allowing for easy tinkering / experimenting by end users, 
I think it might be a good idea to go with the dir with one textfile per mobo.

But less discuss this further tomorrow at our (face to face) meeting. Jean, any 
thoughts / preferences on this?

Regards,

Hans


p.s.

Ed, I'm really glad you've stepped forward with this, it could really be a 
great help!


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ed Lucas]

Ivo Manca wrote:
> I can't seem to find a way to download your software from the site. Is 
> there simply no link, or am I just too tired to see it? :)
Very sorry - my fault! They were on the download page, but hidden. 
Fixed. Here are direct links:
http://sensors4mobo.eberian.com/files/sensors4mobo-client_0.7.tar.gz
http://sensors4mobo.eberian.com/files/sensors4mobo-server_0.4.tar.gz

> If all can be up-and-running by just using the lm-sensors package, why 
> install anything else?
Quite So! Apart from the overlay, sensors4mobo should be redundant once 
your project is finished.

> The web API itself seems to look quite okay, however, I don't agree 
> with one thing:
>
> As I understand it, when the user wants to find a match, he/she sends 
> the dmi-strings to the website, which might give some privacy issues 
> (tbh: I don't care myself ;p). And, the most important thing: when the 
> client's internetconnection is down, or when the website is down, it 
> can't be used anymore. Correct me if I'm wrong.
No, you are right, but the lookup utility allows for an alternative web 
site or a  local folder to be specified (A basic sensors.conf parser was 
written for both server php and and client python scripts)

Reading through your email thread with Jean, your spec looks more full 
featured.

Good point about the privacy. Paranoid users could always create their 
own mirror or campaign for an https interface.

> Having a database is also backwards compatible ;). The user can still 
> decided whether or not to use the dmi-comparison and everything but 
> the sensors-detect is left untouched.
> About making it less easy to copy/duplicate/update using plaintext 
> files: normally I would agree, however, we are are planning on using 
> SQLite as backend. This way, the database will be a single file, and 
> easily distrubuted.
Really, all I am after is an exchange/dump format so that users can mine 
the database easily without having to learn or install a load of new 
tools. Embedding the data in the file achieves this.

I looked at sqlite when developing sensors4mobo but many ISPs do not 
include it and I did not want to add any dependencies that would limit 
usage or make installation harder.


> Having a flag "unsure" (or something similar) to the configuration, 
> makes it possible for users to upload their expirimental sensors.conf 
> files.
Good idea.

> We were thinking about using the following:
> system-manufacturer
> system-product-name
> system-version
> system-serial-number
> baseboard-manufacturer
> baseboard-product-name
> baseboard-version
>
> It seems like these 6 fields covers all motherboards. Sending/storing 
> the serial number might also be a privacy issue.
Good point.

Do you require an exact match on all 7 parameters or do you cherry-pick 
the minimum that identify a motherboard?

> I totally agree with that. I think the ball gets to roll quicker if 
> it's intergrated though ;).
> Anyway, I do encourage everyone to use your sensors4mobo scripts and 
> give us as much feedback as possible. That way, we can make a best 
> effort as possible.
>
> Oh, and if (in the end) we decide to do it my way, the configs aren't 
> uploaded for nothing either! I think it's quite easy to convert them 
> into our database ;)
Yes, my hope is that our 'ways' will converge and that sensors-detect 
will have a sizeable library for when it gets released.

> I don't feel undermined or anything, don't worry ;). However, at the 
> moment, I think our solution is more deserible.
Agreed! I look forward to the outcome, and hope people will start 
emailing in their sensors.conf + dmidecode data.

Best regards,
    Ed


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ivo Manca]

Hey Ed,

> Very sorry - my fault! They were on the download page, but hidden. Fixed. 
> Here are direct links:
> http://sensors4mobo.eberian.com/files/sensors4mobo-client_0.7.tar.gz
> http://sensors4mobo.eberian.com/files/sensors4mobo-server_0.4.tar.gz

Ok, I'll look into them and discuss them with my project members tomorrow.

> Quite So! Apart from the overlay, sensors4mobo should be redundant once 
> your project is finished.
Ok.

> No, you are right, but the lookup utility allows for an alternative web 
> site or a  local folder to be specified (A basic sensors.conf parser was 
> written for both server php and and client python scripts)

That's true. Anyway, when our website is finnished, we will also distribute 
the source of it, so anyone is free to set up their own copy. Since the 
local cache can be easily overwritten by a custom one, I don't think this 
should be a problem. We might also make an optional "location" parameter to 
the sensors-detect script, when the user wants to update.

> Reading through your email thread with Jean, your spec looks more full 
> featured.
>
> Good point about the privacy. Paranoid users could always create their own 
> mirror or campaign for an https interface.
>

> Really, all I am after is an exchange/dump format so that users can mine 
> the database easily without having to learn or install a load of new 
> tools. Embedding the data in the file achieves this.
>
> I looked at sqlite when developing sensors4mobo but many ISPs do not 
> include it and I did not want to add any dependencies that would limit 
> usage or make installation harder.

Hm, let me eleborate a bit.
The user will have a local cache, which is a SQLite database. This can not 
be easily viewed, I agree with that. When a match is found, it will be 
extracted, so the user can make modifications to his/her config.

We are thinking about making the host a website with a MySQL backend. This 
should be easy to realise (since mosts hosts come with it anyway). When the 
config is downloaded, a sqlite file will be extracted from the mysql 
database. How to do this, is not yet defined, but should not be much of a 
trouble. We'll have to look into it.

The website should also allow the users to browse through the available 
config files. This way, the user can easily see how other configs works, if 
he wants to.

It is true that sqlite needs to be installed on the client's pc in order to 
make it run, adding an extra dependency. However, we don't see this is a big 
drawback, since most distributions come with it anyway. As far as I can see 
on my machine:

        libsqlite3.so.0 is needed by (installed) rpm-libs-4.4.2-32.i386
        libsqlite3.so.0 is needed by (installed) rpm-4.4.2-32.i386
        libsqlite3.so.0 is needed by (installed) 
python-sqlite-1.1.7-1.2.1.i386
        libsqlite3.so.0 is needed by (installed) 
yum-metadata-parser-1.0.3-1.fc6.i386
        libsqlite3.so.0 is needed by (installed) apr-util-1.2.8-1.fc6.i386
        sqlite is needed by (installed) mono-data-sqlite-1.1.17.1-4.fc6.i386
        sqlite >= 3.3.1 is needed by (installed) beagle-0.2.13-1.fc6.i386

So it seems like both rpm and yum already use it, which covers most 
distributions, doesn't it?

> Good idea.

>> We were thinking about using the following:
>> system-manufacturer
>> system-product-name
>> system-version
>> system-serial-number
>> baseboard-manufacturer
>> baseboard-product-name
>> baseboard-version
>>
>> It seems like these 6 fields covers all motherboards. Sending/storing the 
>> serial number might also be a privacy issue.

> Good point.
>
> Do you require an exact match on all 7 parameters or do you cherry-pick 
> the minimum that identify a motherboard?

Oops, system-serial-number didn't need to be in that list, making it 6 
fields instead of 7. I was just copy/pasting ;)
Anyway, we do need all the 6 to match. It might be true that some fields 
contain bogus "To-be-filled-in", but if others don't, the combination still 
makes it unique. Stripping it might save some disk space for the database, 
but might also give some complications.
Motherboard manufacturers just seem to randomly fill in either the "system" 
or "baseboard" fields, and sometimes both..

> Yes, my hope is that our 'ways' will converge and that sensors-detect will 
> have a sizeable library for when it gets released.

I hope so too. We won't be able to add a lot more than 5 different 
configurations ourselves, I think, but let's hope people will volenteer soon 
;)

> Agreed! I look forward to the outcome, and hope people will start emailing 
> in their sensors.conf + dmidecode data.

Let's hope so!

Kind regards,

Ivo 


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[David Hubbard]

Hi Ivo, Hans,

> It is true that sqlite needs to be installed on the client's pc in order to
> make it run, adding an extra dependency. However, we don't see this is a big
> drawback, since most distributions come with it anyway. As far as I can see
> on my machine:
>
>         libsqlite3.so.0 is needed by (installed) rpm-libs-4.4.2-32.i386
>         libsqlite3.so.0 is needed by (installed) rpm-4.4.2-32.i386
>         libsqlite3.so.0 is needed by (installed)
> python-sqlite-1.1.7-1.2.1.i386
>         libsqlite3.so.0 is needed by (installed)
> yum-metadata-parser-1.0.3-1.fc6.i386
>         libsqlite3.so.0 is needed by (installed) apr-util-1.2.8-1.fc6.i386
>         sqlite is needed by (installed) mono-data-sqlite-1.1.17.1-4.fc6.i386
>         sqlite >= 3.3.1 is needed by (installed) beagle-0.2.13-1.fc6.i386
>
> So it seems like both rpm and yum already use it, which covers most
> distributions, doesn't it?

I have access to Debian and SuSe machines but I haven't taken the time
to look at the dependencies for sqlite. However, for Gentoo systems,
sqlite won't be there unless the user chooses one of a few packages --
none of which guarantee sqlite will be installed like rpm / yum would
for a Ubuntu, Fedora, or RHEL system. :-(

app-admin/conary
app-misc/beagle
app-misc/cdcollect
app-misc/tracker
app-pda/libopensync
dev-db/sqlitebrowser
dev-db/sqliteodbc
dev-haskell/hdbc-sqlite
dev-haskell/hsql-sqlite
dev-php4/pecl-sqlite
dev-php5/pecl-pdo-sqlite
dev-python/apsw
dev-python/axiom
dev-python/pysqlite
dev-ruby/sqlite-ruby
dev-ruby/sqlite3-ruby
dev-util/nemiver
games-board/slibo
gnustep-apps/gworkspace
kde-misc/katalog
mail-client/mailody
media-gfx/digikam
media-gfx/f-spot
media-sound/banshee
media-sound/bossogg
media-sound/listen
media-sound/monopod
media-tv/dvbstreamer
media-video/mmsv2
net-proxy/vultureng
sys-cluster/csync2

Or, the following packages will use sqlite functionality if the user
configures them to (but don't, by default -- sqlite would be pulled in
when the user is trying to build a system around sqlite, not the other
way around). I notice some important ones here, like rpm, trac, and
qt, but they are probably installed without the sqlite dependency in
most cases.

app-arch/rpm
app-backup/bacula
app-cdr/cdw
app-mobilephone/kannel
app-office/qhacc
app-portage/eix
dev-cpp/sptk
dev-db/hk_classes
dev-db/libdbi-drivers
dev-db/opendbx
dev-db/sqliteodbc
dev-lang/php
dev-lang/python
dev-libs/apr-util
dev-libs/libpreludedb
dev-libs/redland
dev-lisp/cl-sql
dev-ruby/ruby-dbi
dev-util/gambas
games-kids/gcompris
gnome-extra/libgda
kde-misc/krecipes
mail-client/balsa
mail-filter/bogofilter
mail-filter/dspam
mail-mta/exim
media-libs/libsndfile
media-sound/mt-daapd
net-analyzer/ipac-ng
net-analyzer/pmacct
net-dns/pdns
net-im/ekg2
net-im/jabberd
net-mail/dbmail
net-misc/asterisk
net-misc/logjam
net-p2p/gnunet
net-p2p/gtk-gnutella
sci-geosciences/grass
sci-libs/gdal
www-apps/trac
www-servers/lighttpd
x11-libs/qt

Also, look at how sensors uses sensors.conf already. It is a form of
database without needing sqlite. If dmi-detect had a sqlite
dependency, then sensors might one day move the configuration to
sqlite -- reasons why this would be good or bad apply equally to both
apps.

All this is just my opinion, though.

David

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Pinkel]

Hey David,

I should have known about Gentoo. Thanks for pointing this out. We'll
take this with us in the meeting we (Hans, Jasper, Gijs and I) have
today.

Ivo

On 3/28/07, David Hubbard <david.c.hubbard@gmail.com> wrote:
> Hi Ivo, Hans,
>
> > It is true that sqlite needs to be installed on the client's pc in order to
> > make it run, adding an extra dependency. However, we don't see this is a big
> > drawback, since most distributions come with it anyway. As far as I can see
> > on my machine:
> >
> >         libsqlite3.so.0 is needed by (installed) rpm-libs-4.4.2-32.i386
> >         libsqlite3.so.0 is needed by (installed) rpm-4.4.2-32.i386
> >         libsqlite3.so.0 is needed by (installed)
> > python-sqlite-1.1.7-1.2.1.i386
> >         libsqlite3.so.0 is needed by (installed)
> > yum-metadata-parser-1.0.3-1.fc6.i386
> >         libsqlite3.so.0 is needed by (installed) apr-util-1.2.8-1.fc6.i386
> >         sqlite is needed by (installed) mono-data-sqlite-1.1.17.1-4.fc6.i386
> >         sqlite >= 3.3.1 is needed by (installed) beagle-0.2.13-1.fc6.i386
> >
> > So it seems like both rpm and yum already use it, which covers most
> > distributions, doesn't it?
>
> I have access to Debian and SuSe machines but I haven't taken the time
> to look at the dependencies for sqlite. However, for Gentoo systems,
> sqlite won't be there unless the user chooses one of a few packages --
> none of which guarantee sqlite will be installed like rpm / yum would
> for a Ubuntu, Fedora, or RHEL system. :-(
>
> app-admin/conary
> app-misc/beagle
> app-misc/cdcollect
> app-misc/tracker
> app-pda/libopensync
> dev-db/sqlitebrowser
> dev-db/sqliteodbc
> dev-haskell/hdbc-sqlite
> dev-haskell/hsql-sqlite
> dev-php4/pecl-sqlite
> dev-php5/pecl-pdo-sqlite
> dev-python/apsw
> dev-python/axiom
> dev-python/pysqlite
> dev-ruby/sqlite-ruby
> dev-ruby/sqlite3-ruby
> dev-util/nemiver
> games-board/slibo
> gnustep-apps/gworkspace
> kde-misc/katalog
> mail-client/mailody
> media-gfx/digikam
> media-gfx/f-spot
> media-sound/banshee
> media-sound/bossogg
> media-sound/listen
> media-sound/monopod
> media-tv/dvbstreamer
> media-video/mmsv2
> net-proxy/vultureng
> sys-cluster/csync2
>
> Or, the following packages will use sqlite functionality if the user
> configures them to (but don't, by default -- sqlite would be pulled in
> when the user is trying to build a system around sqlite, not the other
> way around). I notice some important ones here, like rpm, trac, and
> qt, but they are probably installed without the sqlite dependency in
> most cases.
>
> app-arch/rpm
> app-backup/bacula
> app-cdr/cdw
> app-mobilephone/kannel
> app-office/qhacc
> app-portage/eix
> dev-cpp/sptk
> dev-db/hk_classes
> dev-db/libdbi-drivers
> dev-db/opendbx
> dev-db/sqliteodbc
> dev-lang/php
> dev-lang/python
> dev-libs/apr-util
> dev-libs/libpreludedb
> dev-libs/redland
> dev-lisp/cl-sql
> dev-ruby/ruby-dbi
> dev-util/gambas
> games-kids/gcompris
> gnome-extra/libgda
> kde-misc/krecipes
> mail-client/balsa
> mail-filter/bogofilter
> mail-filter/dspam
> mail-mta/exim
> media-libs/libsndfile
> media-sound/mt-daapd
> net-analyzer/ipac-ng
> net-analyzer/pmacct
> net-dns/pdns
> net-im/ekg2
> net-im/jabberd
> net-mail/dbmail
> net-misc/asterisk
> net-misc/logjam
> net-p2p/gnunet
> net-p2p/gtk-gnutella
> sci-geosciences/grass
> sci-libs/gdal
> www-apps/trac
> www-servers/lighttpd
> x11-libs/qt
>
> Also, look at how sensors uses sensors.conf already. It is a form of
> database without needing sqlite. If dmi-detect had a sqlite
> dependency, then sensors might one day move the configuration to
> sqlite -- reasons why this would be good or bad apply equally to both
> apps.
>
> All this is just my opinion, though.
>
> David
>

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ed Lucas]

Morning All,
>>> We were thinking about using the following:
>>> system-manufacturer
>>> system-product-name
>>> system-version
>>> baseboard-manufacturer
>>> baseboard-product-name
>>> baseboard-version
I have cobbled together new versions of the sensors4mobo tools that only 
use those six parameters. The web server now does a very basic check for 
six parameters and the table marks the broken ones (loads more work & 
sanity checking to be done here). One valid file so far, and I will see 
about updating the rest when I have the time.

I have also added a "tags" field in which you can add a fixed set of 
tags to describe the file: so far I have thought of "broken", 
"experimental" and "beta". Perhaps this goes some way towards emulating 
your "unsure" database flag, Ivo? I went for the name "tags" rather than 
"status" so that other info could be added with minimal api changes. 
This is more for my sensors overlay work, so feel free to disregard it 
if it doesn't fit your goals.

Can anyone point me towards a description of the "dynamic chips support" 
for libsensors that Jean mentioned. (Sorry, my googling failed on this).

For motherboard specific sensors.conf files, would it make sense to use 
the same fan labels that are used in the manual and on the motherboard 
itself? (What is the offical naming policy? - grepping  sensors.conf 
shows a range of names)

Best regards,
    Ed

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ivo Manca]

Hey Ed,

First of all, let me give you a quick update.

This morning, we had a meeting with our project supervisor (Hans de Goede) 
and discussed the pro's and con's about using SQLite versus plain text 
files. We've decided to go for the latter, your option. The fact that you've 
already written a parser is a big advantage too.

Anyway, we decided to split the project in three parts for now:

* the sensors-detect program (Ivo Manca)
- Reads dmidecoded and finds a match. Also ability to update local cache.

* the website (Jasper Alias)
- Ability for users to submit their configs, look through configs and 
vote/rank/moderate  them.

* submission of configs (Gijs van der Weg)
- Manual versus automatic? Best for users? Best for maintance?

This way we can all work on the project without slowing eachother down.
I'll mainly focus on the sensors-detect script itself.

Mainly, it means that we will have to modify sensors-detect to:
* add support the looking up of the neccesary dmidecode strings (Done: 
copied a piece of code that Jean submitted a while ago)
* add support for command line parameters (Probing? Dmi? Help? Verbose?)
* add support for finding a match in the files
* applying this config and modprobing, using the functions already available 
in sensors-detect

I think I'll be able to use quite a lot of your code, I'll just need to 
parse it to perl and modify some things ;)

One thing I noticed, looking through your code, was the fact that your 
script is capable of finding multipe matches. I wonder whether or not this 
is something we want to have there?
Giving a random, unique DMI string, there should only be one possible 
configuration, unless the dmistrings are bogus.

It is possible that users want to improve the config, but then he or she 
should just modify the existing and upload it, isn't it?
So I don't really see a point of supporting more matches. Maybe I'm 
overlooking something.

> I have cobbled together new versions of the sensors4mobo tools that only 
> use those six parameters. The web server now does a very basic check for 
> six parameters and the table marks the broken ones (loads more work & 
> sanity checking to be done here). One valid file so far, and I will see 
> about updating the rest when I have the time.

> I have also added a "tags" field in which you can add a fixed set of tags 
> to describe the file: so far I have thought of "broken", "experimental" 
> and "beta". Perhaps this goes some way towards emulating your "unsure" 
> database flag, Ivo? I went for the name "tags" rather than "status" so 
> that other info could be added with minimal api changes. This is more for 
> my sensors overlay work, so feel free to disregard it if it doesn't fit 
> your goals.

Sounds good. Maybe add a final as well?

> Can anyone point me towards a description of the "dynamic chips support" 
> for libsensors that Jean mentioned. (Sorry, my googling failed on this).
>
> For motherboard specific sensors.conf files, would it make sense to use 
> the same fan labels that are used in the manual and on the motherboard 
> itself? (What is the offical naming policy? - grepping  sensors.conf shows 
> a range of names)

I've seen it being mentioned various times, but I don't think I can help you 
out with it.

Ivo 


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ed Lucas]

Hi Folks,

Ivo Manca wrote:
...
> One thing I noticed, looking through your code, was the fact that your 
> script is capable of finding multipe matches. I wonder whether or not 
> this is something we want to have there?
> Giving a random, unique DMI string, there should only be one possible 
> configuration, unless the dmistrings are bogus.
>
> It is possible that users want to improve the config, but then he or 
> she should just modify the existing and upload it, isn't it?
> So I don't really see a point of supporting more matches. Maybe I'm 
> overlooking something.
Erm, that was speculative - The fear was that a BIOS update might change 
the dmidecode info. In that case, it would be cleanest to allow multiple 
matches in the one file instead of forcing users to create duplicate 
sensors.conf files for each BIOS.

I don't know if this is actually a real risk or not. Has anyone found 
BIOS updates changing the six key parameters?


>> I have also added a "tags" field in which you can add a fixed set of 
>> tags to describe the file: so far I have thought of "broken", 
>> "experimental" and "beta". Perhaps this goes some way 
>> towardsemulating your "unsure" database flag, Ivo? I went for the 
>> name "tags" rather than "status" so that other info could be added 
>> with minimal api changes. This is more for my sensors overlay work, 
>> so feel free to disregard it if it doesn't fit your goals.
>
> Sounds good. Maybe add a final as well?
I was thinking it would be easier to make that implicit? i.e. only add a 
tag in the special cases. It might well be worth putting in though, as a 
seal of approval.


>> Can anyone point me towards a description of the "dynamic chips 
>> support" for libsensors that Jean mentioned. (Sorry, my googling 
>> failed on this).
>>
>> For motherboard specific sensors.conf files, would it make sense to 
>> use the same fan labels that are used in the manual and on the 
>> motherboard itself? (What is the offical naming policy? - grepping  
>> sensors.conf shows a range of names)
>
> I've seen it being mentioned various times, but I don't think I can 
> help you out with it.
I will keep looking.

Gook luck,
    Ed


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Hans de Goede]

Ed Lucas wrote:
 >
> Can anyone point me towards a description of the "dynamic chips support" 
> for libsensors that Jean mentioned. (Sorry, my googling failed on this).
>

Currently libsensors has a table, with for each supported chip a table in this 
table (thus a tabel of tables) the per chip table lists all the features of the 
chip and how they are related to each other (IOW if they share computation 
rules, etc).

The big downside of this is that every time a new chip gets supported (like the 
uguru) then this table and thus libsensors need to be updated. Since some 
distro's tend to update the kernel more often then userspace libs, this means 
that people can have a kernel supported chip which is not working because 
libsensors doesn't understand it.

With the new sysfs interface in kernel 2.6, all the needed information can 
actually be "queried" from the sysfs interface, thus removing the need for this 
table, this is what we call "dynamic chips support", AFAIK the impact on the 
dmi based autoconfig stuff we're working on is minimal. The only relevant 
change is the libsensors names of sensors. For most chips sensors currently are 
named things like in0, in1, etc. So one can write:
label in1 "foo bar"

However some chips (GRRR) have names like VDD5V, so one should write:
label VDD5V "foo bar"

With dynamic chip supports, things become consistent and for example volt 
sensors will always be called in0 in1, etc. This actually is an improvement, 
but does mean that old sensors.conf's need to be converted. This is very much 
AFAIK, others please correct me if I'm wrong here.

As discussed earlier the plan is to only target the new 3.x version of 
libsensors with the dmi based stuff, so there is no real problem, we just need 
to make sure any sensors.conf files in the "database" use the new names.

> For motherboard specific sensors.conf files, would it make sense to use 
> the same fan labels that are used in the manual and on the motherboard 
> itself? (What is the offical naming policy? - grepping  sensors.conf 
> shows a range of names)
> 

For the abituguru files in the wiki I've tried to use the exact same names as 
in the bios. AFAIK there is no policy for this. Also notice that libsensors 3.x 
will have a new api funciton, allowing one to query the type of a sensor, so 
then it will not be needed to prefix labels like you've done to find out the type.

Regards,

Hans


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

On Thu, 29 Mar 2007 10:03:11 +0200, Pinkel wrote:
> I should have known about Gentoo. Thanks for pointing this out. We'll
> take this with us in the meeting we (Hans, Jasper, Gijs and I) have
> today.

For what it's worth, Slackware doesn't package sqlite at all.

-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Hans,

On Wed, 28 Mar 2007 13:20:33 +0200, Hans de Goede wrote:
> Ivo Manca wrote:
> > Hey Ed,
> > 
> >> I looked at sqlite when developing sensors4mobo but many ISPs do not 
> >> include it and I did not want to add any dependencies that would limit 
> >> usage or make installation harder.
> 
> <lots of explanation by Ivo about sqlite plans snipped>
> 
> Actually I have been thinking about using the annotating of sensors.conf file 
> myself in the past, but I thought sqlite would be easier to use, esp. on the 
> web-side. Since with sensors4mobo we kinda get the web-side for free, and I 
> also _really_ like the idea of the database being a dir of textfiles with one 
> file per motherboard allowing for easy tinkering / experimenting by end users, 
> I think it might be a good idea to go with the dir with one textfile per mobo.
> 
> But less discuss this further tomorrow at our (face to face) meeting. Jean, any 
> thoughts / preferences on this?

For the local data, I'd go for text files. Each motherboard being
uniquely identified by a finite number of DMI strings, we can
combine them to form a unique identifier and use that in the
configuration file name. Ideally this should be something like
sensors-$manufacturer-$model-$version.conf, but we'll see how it goes
in practice. With this naming convention, lookups are in O(1), which is
perfect.

Now, it might still be good to have a database as the backend of the
website, that's a different story. It should be easy enough to generate
all the text files from the database, adding metadata as comments at
the beginning of the files.

-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Ivo,

On Wed, 28 Mar 2007 14:07:18 +0200, Ivo Manca wrote:
> >> We were thinking about using the following:
> >> system-manufacturer
> >> system-product-name
> >> system-version
> >> system-serial-number
> >> baseboard-manufacturer
> >> baseboard-product-name
> >> baseboard-version
> >>
> >> It seems like these 6 fields covers all motherboards. Sending/storing the 
> >> serial number might also be a privacy issue.
> 
> > Good point.
> >
> > Do you require an exact match on all 7 parameters or do you cherry-pick 
> > the minimum that identify a motherboard?
> 
> Oops, system-serial-number didn't need to be in that list, making it 6 
> fields instead of 7. I was just copy/pasting ;)
> Anyway, we do need all the 6 to match. It might be true that some fields 

I believe that non-matching version numbers should not be fatal. It
sometimes happen that different versions of a board need different
configuration files, true, but it's rather rare, so we don't want to
store one configuration file per version in general, that would be
overkill; we'll only do so when really needed.

So I think we should try to match all 6 fields first, if it fails, try
without the versions (so only 4 fields), and only if that fails too,
declare that no matching configuration file was found.

-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Ed,

On Thu, 29 Mar 2007 11:00:32 +0100, Ed Lucas wrote:
> I have also added a "tags" field in which you can add a fixed set of 
> tags to describe the file: so far I have thought of "broken", 
> "experimental" and "beta". Perhaps this goes some way towards emulating 
> your "unsure" database flag, Ivo? I went for the name "tags" rather than 
> "status" so that other info could be added with minimal api changes. 
> This is more for my sensors overlay work, so feel free to disregard it 
> if it doesn't fit your goals.

Random idea: we could add an architecture tag to configuration files.
There's no point in installing files for x86 motherboards on an x86_64
distribution for example. This would allow distributions to split the
configuration files to multiple packages and only includes the ones
they want.

-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Ivo,

On Thu, 29 Mar 2007 15:20:53 +0200, Ivo Manca wrote:
> One thing I noticed, looking through your code, was the fact that your 
> script is capable of finding multipe matches. I wonder whether or not this 
> is something we want to have there?
> Giving a random, unique DMI string, there should only be one possible 
> configuration, unless the dmistrings are bogus.
> 
> It is possible that users want to improve the config, but then he or she 
> should just modify the existing and upload it, isn't it?
> So I don't really see a point of supporting more matches. Maybe I'm 
> overlooking something.

Different people might upload a configuration file for the same
motherboard, in the "unconfirmed" state or whatever we call it. Until
someone reviews them, validates one of them and discards the other, we
have two files for the same board. So yes, it can happen. There should
never be several "confirmed" configuration files for a given board,
though.

Now, what is true of the website database may not be true of the local
cache (files in a directory, if we do that.) We may decide to only
export the confirmed files for the cache, for example, or only one of
the possible configurations (maybe based on a mark given by the site
visitors.) I have no strong opinion on this.

-- 
Jean Delvare

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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Ivo Manca]

Hey Jean,

Thanks for pointing out Slackware :), but we won't be using a DBMS anymore 
(for the clientside).

> For the local data, I'd go for text files. Each motherboard being
> uniquely identified by a finite number of DMI strings, we can
> combine them to form a unique identifier and use that in the
> configuration file name. Ideally this should be something like
> sensors-$manufacturer-$model-$version.conf, but we'll see how it goes
> in practice. With this naming convention, lookups are in O(1), which is
> perfect.
>
> Now, it might still be good to have a database as the backend of the
> website, that's a different story. It should be easy enough to generate
> all the text files from the database, adding metadata as comments at
> the beginning of the files.

> Looking up will indeed go lots faster that way, so I think that idea is 
> not bad at all.
> I think using a (MySQL) database on the website will be a big pro.

> I believe that non-matching version numbers should not be fatal. It
> sometimes happen that different versions of a board need different
> configuration files, true, but it's rather rare, so we don't want to
> store one configuration file per version in general, that would be
> overkill; we'll only do so when really needed.

> So I think we should try to match all 6 fields first, if it fails, try
> without the versions (so only 4 fields), and only if that fails too,
> declare that no matching configuration file was found.

True, should make it more usable.

> Random idea: we could add an architecture tag to configuration files.
> There's no point in installing files for x86 motherboards on an x86_64
> distribution for example. This would allow distributions to split the
> configuration files to multiple packages and only includes the ones
> they want.

Noted, we'll think about this one.

> Different people might upload a configuration file for the same
> motherboard, in the "unconfirmed" state or whatever we call it. Until
> someone reviews them, validates one of them and discards the other, we
> have two files for the same board. So yes, it can happen. There should
> never be several "confirmed" configuration files for a given board,
> though.

> Now, what is true of the website database may not be true of the local
> cache (files in a directory, if we do that.) We may decide to only
> export the confirmed files for the cache, for example, or only one of
> the possible configurations (maybe based on a mark given by the site
> visitors.) I have no strong opinion on this.

Why not make the user decide about this? Default option: only confirmed. But 
a posibility to download the "unconfirmed/experimental" ones also.
Ofcourse, we'll have to notify the user with  "These configs are not tested, 
bla bla bla".

Thanks for your input.

Ivo 


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

Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)

[Jean Delvare]

Hi Ivo,

On Wed, 4 Apr 2007 11:34:37 +0200, Ivo Manca wrote:
> > Now, what is true of the website database may not be true of the local
> > cache (files in a directory, if we do that.) We may decide to only
> > export the confirmed files for the cache, for example, or only one of
> > the possible configurations (maybe based on a mark given by the site
> > visitors.) I have no strong opinion on this.
> 
> Why not make the user decide about this? Default option: only confirmed. But 
> a posibility to download the "unconfirmed/experimental" ones also.
> Ofcourse, we'll have to notify the user with  "These configs are not tested, 
> bla bla bla".

In practice, this will end up being a choice made by the distribtions
rather than individual users. But yes, we can leave the choice and see
what distributions decide to do.

-- 
Jean Delvare

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