* [lm-sensors] Sensors-detect with DMI detection
@ 2007-02-22 14:40 Ivo Manca
2007-02-22 17:19 ` Jean Delvare
` (18 more replies)
0 siblings, 19 replies; 20+ messages in thread
From: Ivo Manca @ 2007-02-22 14:40 UTC (permalink / raw)
To: lm-sensors
Hey all,
We are three Computer Science students from the TH Rijswijk in the
Netherlands. Hans de Goede, our project supervisor, suggested it would be a
good idea to work on the LM sensors detection script. After hearing his
idea, we decided this could be a good idea and started to write a project
plan.
Mainly, it means that the sensor-detect script will be extended with
detection through DMI. It does not mean that the probing will be removed.
The project plan can be found at
http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
Here you can find all information about our goal. We hope you think the
extension
will be useful and wanted. Suggestions and feedback are always welcome.
Ivo Manca, Project Leader
Jasper Alias
Gijs van der Weg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070222/64937185/attachment.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
@ 2007-02-22 17:19 ` Jean Delvare
2007-02-23 7:08 ` Hans de Goede
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-02-22 17:19 UTC (permalink / raw)
To: lm-sensors
Hi Ivo,
On Thu, 22 Feb 2007 15:40:18 +0100, Ivo Manca wrote:
> We are three Computer Science students from the TH Rijswijk in the
> Netherlands. Hans de Goede, our project supervisor, suggested it would be a
> good idea to work on the LM sensors detection script. After hearing his
> idea, we decided this could be a good idea and started to write a project
> plan.
>
> Mainly, it means that the sensor-detect script will be extended with
> detection through DMI. It does not mean that the probing will be removed.
>
> The project plan can be found at
> http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
> Here you can find all information about our goal. We hope you think the
> extension
> will be useful and wanted. Suggestions and feedback are always welcome.
This sounds like a good plan, however I'd like to make sure that you do
not duplicate efforts that have been going on in this area:
1* Back in November 2006, I proposed a patch to sensors-detect to print
the DMI data at the beginning of sensors-detect:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-November/018245.html
There was zero feedback so I did not apply it, however it might be a
good base for what you want to implement now.
2* Back in September 2006, Ivan Barrera proposed something named
"sconfig" which looked very similar to your own proposal:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-September/017623.html
Unfortunately, nobody paid attention to this, despite the fact that
everybody seems to agree that such a tool is highly needed. So maybe
you want to look at whan Ivan did and/or take contact with him.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
2007-02-22 17:19 ` Jean Delvare
@ 2007-02-23 7:08 ` Hans de Goede
2007-02-27 8:50 ` Jean Delvare
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2007-02-23 7:08 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Hi Ivo,
>
>
> This sounds like a good plan, however I'd like to make sure that you do
> not duplicate efforts that have been going on in this area:
>
>
> 2* Back in September 2006, Ivan Barrera proposed something named
> "sconfig" which looked very similar to your own proposal:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-September/017623.html
> Unfortunately, nobody paid attention to this, despite the fact that
> everybody seems to agree that such a tool is highly needed. So maybe
> you want to look at whan Ivan did and/or take contact with him.
>
Actually I did pay attention, as Ivan was doing this for a Google Summer of
Code project, which was initiated by my from under the Fedora project umbrella.
Since I was Ivan's mentor that project I did closely follow his work, but
unfortunately his results where not all that I had hoped for. Hence this new
attempt, with lessons learned from the Ivan story. I've already given my
students a link to the website where Ivan's stuff is hosted and told them to
take a look at the things done and source code created by Ivan as a start.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
2007-02-22 17:19 ` Jean Delvare
2007-02-23 7:08 ` Hans de Goede
@ 2007-02-27 8:50 ` Jean Delvare
2007-02-27 10:59 ` Ivo Manca
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-02-27 8:50 UTC (permalink / raw)
To: lm-sensors
Hi Ivo,
On Thu, 22 Feb 2007 15:40:18 +0100, Ivo Manca wrote:
> The project plan can be found at
> http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
> Here you can find all information about our goal. We hope you think the
> extension
> will be useful and wanted. Suggestions and feedback are always welcome.
I've read the "Background Information" and "Objectives" parts, overall
it looks good, except that a proofread of the document would be very
welcome.
My comments:
* The primary objective mentions an "internal database". I'm not sure
what "internal" is supposed to mean here. Do you plan to embed a big
array of known motherboards inside the sensors-detect script itself?
* I'm very much in favor of command line parameters being added to
sensors-detect so that for example a non-interactive mode can be
supported. I wanted to do that myself for some time but could never
find the time to actually do it. Another useful mode would be a "quiet"
mode, which would hide all the details and present the probing summary.
It would still be interactive in that it should not overwrite the
configuration file without the user's consent, so it would be somewhat
intermediate between the current mode and a fully automated mode.
BTW, I think you really mean "first objective" and "second objective",
not primary and secondary.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (2 preceding siblings ...)
2007-02-27 8:50 ` Jean Delvare
@ 2007-02-27 10:59 ` Ivo Manca
2007-02-27 11:43 ` Jean Delvare
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Ivo Manca @ 2007-02-27 10:59 UTC (permalink / raw)
To: lm-sensors
Hey Jean,
First of all, sorry for my late response.
> I've read the "Background Information" and "Objectives" parts, overall
> it looks good, except that a proofread of the document would be very
> welcome.
We've tried to fix most of the errors and typo's in the document before
sending in to the mailing list. However, English is not our main language
and because of our school's short time limit there still may be some errors.
Thanks for noticing it, we will check the document again and post an updated
version as soon as possible.
> My comments:
>
> * The primary objective mentions an "internal database". I'm not sure
> what "internal" is supposed to mean here. Do you plan to embed a big
> array of known motherboards inside the sensors-detect script itself?
In this case, internal means that the database is stored on the user's
computer. The reason we mentioned this is because we first considered an
option which makes the script connect to the corresponding website. This
however does not seem to be a very welcome "feature".
The actual place were the database will be stored is not yet decided.
> * I'm very much in favor of command line parameters being added to
> sensors-detect so that for example a non-interactive mode can be
> supported. I wanted to do that myself for some time but could never
> find the time to actually do it. Another useful mode would be a "quiet"
> mode, which would hide all the details and present the probing summary.
> It would still be interactive in that it should not overwrite the
> configuration file without the user's consent, so it would be somewhat
> intermediate between the current mode and a fully automated mode.
It seems that this did not end up in the final version of the project plan
but this was also our view.
The command line switches we were thinking of adding, include:
* An automatic (or: non-interactive) mode, which will only use the DMI
information to detect the sensors.
* A mode which first uses the DMI information and then asks whether or not
the user wants to probe afterwards.
* A probing-only mode. For various reasons it might be welcome to keep this
mode, for example: if for some reason the DMI information is bogus.
This automatic mode could also be very useful for newly installed
configurations. In this case the user will already have a configured
sensors.conf and is able to use the software "out-of-the-box". However, this
is just a thought.
We've already figured out that the default option of sensors-detect should
not overwrite an existing configuration file without asking first. It might
give some frustration to the users..
> BTW, I think you really mean "first objective" and "second objective",
> not primary and secondary.
We meant: "Most important" and "Less important". I thought primary and
secondary was a correct translation for this. They both still need to (and
will) be completed though.
Ivo Manca
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (3 preceding siblings ...)
2007-02-27 10:59 ` Ivo Manca
@ 2007-02-27 11:43 ` Jean Delvare
2007-02-27 12:24 ` Ivo Manca
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-02-27 11:43 UTC (permalink / raw)
To: lm-sensors
Hi Ivo,
On Tue, 27 Feb 2007 11:59:03 +0100, Ivo Manca wrote:
> Hey Jean,
>
> First of all, sorry for my late response.
Late response? You replied within 2 hours, it took me four days ;)
> > My comments:
> >
> > * The primary objective mentions an "internal database". I'm not sure
> > what "internal" is supposed to mean here. Do you plan to embed a big
> > array of known motherboards inside the sensors-detect script itself?
>
> In this case, internal means that the database is stored on the user's
> computer. The reason we mentioned this is because we first considered an
In this case the correct term would be "local", not "internal".
> option which makes the script connect to the corresponding website. This
> however does not seem to be a very welcome "feature".
I think it is. There's nothing wrong with fetching data file updates
from the net. New motherboard models are released so frequently that
it's very likely that the user won't find his model in the local
database (provided by his distribution, so including a 6 to 9-month old
version of lm_sensors.) A remote repository makes sense IMHO.
But of course having a local cache can be good too. Not everyone has a
permanent access to Internet, and our server might be temporarily
unresponsive or be moved to a different location.
So both options are really open. It's up to you. Either option will be
better than what we currently have anyway :)
>
> The actual place were the database will be stored is not yet decided.
>
> > * I'm very much in favor of command line parameters being added to
> > sensors-detect so that for example a non-interactive mode can be
> > supported. I wanted to do that myself for some time but could never
> > find the time to actually do it. Another useful mode would be a "quiet"
> > mode, which would hide all the details and present the probing summary.
> > It would still be interactive in that it should not overwrite the
> > configuration file without the user's consent, so it would be somewhat
> > intermediate between the current mode and a fully automated mode.
>
> It seems that this did not end up in the final version of the project plan
> but this was also our view.
> The command line switches we were thinking of adding, include:
> * An automatic (or: non-interactive) mode, which will only use the DMI
> information to detect the sensors.
> * A mode which first uses the DMI information and then asks whether or not
> the user wants to probe afterwards.
> * A probing-only mode. For various reasons it might be welcome to keep this
> mode, for example: if for some reason the DMI information is bogus.
I'm not sure it makes sense to have command line switches for the
interactive mode itself. You can simply propose the user to check the
DMI table (default Y), then propose to probe the hardware (default N if
the system was found in the database.)
The command line options would be most valuable for the non-interactive
mode: one option to only use the DMI database, one option to only use
probing, one option to try DMI first then fallback to probing.
> This automatic mode could also be very useful for newly installed
> configurations. In this case the user will already have a configured
> sensors.conf and is able to use the software "out-of-the-box". However, this
> is just a thought.
Agreed.
> We've already figured out that the default option of sensors-detect should
> not overwrite an existing configuration file without asking first. It might
> give some frustration to the users..
True. That being said, in non-interactive mode, it might make sense to
backup the old config file and write the new one (by default or with an
option.)
> > BTW, I think you really mean "first objective" and "second objective",
> > not primary and secondary.
>
> We meant: "Most important" and "Less important". I thought primary and
> secondary was a correct translation for this. They both still need to (and
> will) be completed though.
If you meant "most important" and "less important" then "primary" and
"secondary" are correct. But my understanding is that the first
objective is a required prerequisite to implement the second one, too.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (4 preceding siblings ...)
2007-02-27 11:43 ` Jean Delvare
@ 2007-02-27 12:24 ` Ivo Manca
2007-02-27 20:41 ` Rudolf Marek
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Ivo Manca @ 2007-02-27 12:24 UTC (permalink / raw)
To: lm-sensors
Hey Jean
> Late response? You replied within 2 hours, it took me four days ;)
True; this response was quite fast. I was actually thinking about the first
post of yours and my first response in general ;)
> In this case the correct term would be "local", not "internal".
How obvious; you're right.
> I think it is. There's nothing wrong with fetching data file updates
> from the net. New motherboard models are released so frequently that
> it's very likely that the user won't find his model in the local
> database (provided by his distribution, so including a 6 to 9-month old
> version of lm_sensors.) A remote repository makes sense IMHO.
>
> But of course having a local cache can be good too. Not everyone has a
> permanent access to Internet, and our server might be temporarily
> unresponsive or be moved to a different location.
>
> So both options are really open. It's up to you. Either option will be
> better than what we currently have anyway :)
The local cache is something we wanted to use no matter what. It can be very
annoying if software doesn't work, simply because you don't have an internet
connection at that moment. But, the cache can get out-dated.
I agree that it should be able to update this cache but I'm not sure yet
how. Should the sensors_detect script try and find a new data file every
time it's executed with DMI support, or should it get a parameter for either
enabling or disabling this feature? That's something we've got to give a
thought.
> I'm not sure it makes sense to have command line switches for the
> interactive mode itself. You can simply propose the user to check the
> DMI table (default Y), then propose to probe the hardware (default N if
> the system was found in the database.)
>
> The command line options would be most valuable for the non-interactive
> mode: one option to only use the DMI database, one option to only use
> probing, one option to try DMI first then fallback to probing.
That actually sums up every sensible option, doesn't it? ;). Right now, I
can't find a reason not to do it that way.
> True. That being said, in non-interactive mode, it might make sense to
> backup the old config file and write the new one (by default or with an
> option.)
Agree.
> If you meant "most important" and "less important" then "primary" and
> "secondary" are correct. But my understanding is that the first
> objective is a required prerequisite to implement the second one, too.
It is.
However, we are not sure yet if we're going to completely implement the
first objective first, before starting on the second. If we make a good
design for both objectives we are able to script this webinterface in
relatively little time. This can be a big advantage since we only got a
fixed amount of weeks to finish this assignment for school ("if we fix
things afterwards, they don't count for the project anymore"). After this
website is "live" we can easily gather information from various users and
configurations, which makes it easier to find (and fix) bugs in an early
stage.
After the detection script seems to be more than capable of doing the job,
we we can expand the webinterface to make it more user friendly, depending
on progress being made.
I hope this clarifies it a bit. I'm not sure whether or not "Primary" and
"Secondary" are the correct terms to use, but it seems to cause confusion so
it obviously isn't. We should modify that chapter and add some explanation
there ;)
Ivo
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (5 preceding siblings ...)
2007-02-27 12:24 ` Ivo Manca
@ 2007-02-27 20:41 ` Rudolf Marek
2007-02-28 13:35 ` Hans de Goede
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Rudolf Marek @ 2007-02-27 20:41 UTC (permalink / raw)
To: lm-sensors
Hello Ivo,
Back in the 2004 (12.06.2004 15:04 ;) I collected some DMI strings from
different machines, please check the attachment for some summary and bellow for
the 2004 raw data.
Rudolf
DMI type 1, 25 bytes.
System Information
Manufacturer: ASUSTeK Computer INC.
Product Name: A7N8X2.0
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: A7N8X2.0
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: Chassis Manufactture
Type: Desktop
DMI type 1, 25 bytes.
System Information
Manufacturer: IBM
Product Name: 2722CDG
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: IBM
Product Name: 2722CDG
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: IBM
Type: Notebook
ANd from my computer in prague.
DMI type 1, 25 bytes.
System Information Block
Vendor: System Manufacturer
Product: System Name
--
DMI type 2, 8 bytes.
Board Information Block
Vendor: ASUSTeK Computer INC.
Product: P4B533-E
--
DMI type 3, 17 bytes.
Chassis Information Block
Vendor: Chassis Manufacture
Chassis Type: Tower
triton:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: VIA Technologies, Inc.
Product Name: VT8366/A-8233
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: <BAD INDEX>
Product Name: <BAD INDEX>
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: <BAD INDEX>
Type: Desktop
--
DMI type 3, 4 bytes.
Chassis Information
Handle 0x001C
DMI type 17, 27 bytes.
BListy:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: Intel Corporation
Product Name: SE7505VB2
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Intel Corporation
Product Name: SE7505VB2 Board
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: No Enclosure
Type: Tower
jhr:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: VIA Technologies, Inc.
Product Name: VT82C692BX
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer:
Product Name: 693-596-ITE
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer:
Type: Unknown
Imladris:/home/joe# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: VIA Technologies, Inc.
Product Name: VT8363
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer:
Product Name: 8363-686B
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer:
Type: Desktop
ssh:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: To be Filled
Product Name: To be Filled
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Supermicro Inc.
Product Name: Intel 440BX/440GX
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: To be Filled
Type: Desktop
Lothlorien:/home/joe# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: Acer
Product Name: TravelMate 220
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Acer
Product Name: Intel Almador-M
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: Acer
Type: Notebook
jboss:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: IBM
Product Name: 6893520
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: IBM
Product Name: 6893520
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: IBM
Type: Desktop
Moria:~# dmidecode
# dmidecode 2.4
# No SMBIOS nor DMI entry point found, sorry.
Dylan:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 8 bytes.
System Information
Manufacturer:
Product Name:
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer:
Product Name: i430TX-8679
--
DMI type 3, 9 bytes.
Chassis Information
Manufacturer:
Type: Unknown
r3:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer: Intel
Product Name:
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Intel
Product Name: SE7501WV2S
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Intel Corporation
Type: Rack Mount Chassis
gw:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 25 bytes.
System Information
Manufacturer:
Product Name:
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Intel Corporation
Product Name: D815EPE2U
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer:
Type: Unknown
Gondolin:~# dmidecode|grep -A 3 'type [123],'
DMI type 1, 8 bytes.
System Information
Manufacturer: System Manufacturer
Product Name: System Name
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: P2B
--
DMI type 3, 9 bytes.
Chassis Information
Manufacturer: Chassis Manufacture
Type: Unknown
root at service:~# dmidecode |grep -A 3 "type [123]," DMI type 1, 25
bytes.
System Information
Manufacturer: System Manufacturer
Product Name: System Name
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: PU-DLS
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Chassis Manufacture
Type: Tower
DMI type 1, 25 bytes.
System Information
Manufacturer:
Product Name:
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Intel Corporation
Product Name: D815EPFV
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer:
Type: Unknown
nms1:~# dmidecode |grep -A 3 "type [123],"
DMI type 1, 25 bytes.
System Information
Manufacturer:
Product Name:
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Gigabyte Technology Co. Ltd.
Product Name: i440BX-W977
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer:
Type: Unknown
(nms1.sh)
b0re:/home/wilder# dmidecode |grep -A 3 "type [123],"
DMI type 1, 25 bytes.
System Information
Manufacturer: System Manufacturer
Product Name: System Name
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: P4S8X-X
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Chassis Manufacture
Type: Tower
(hysteria.cz)
and this only from one grep
[15:07] <@jammic> jedina informacia z toho grepu je
Product
Name: i440BX-W83977
[15:07] <@jammic> Type: Desktop
fw:~# dmidecode |grep -A 3 "type [123],"
DMI type 1, 25 bytes.
System Information
Manufacturer: Dell Computer Corp.
Product Name: PowerEdge 350
--
DMI type 2, 8 bytes.
Base Board Information
Manufacturer: Intel Corporation
Product Name: TR440BXA
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer:
Type: Unknown
(zakaznik c.1)
DMI type 1, 25 bytes.
System Information
Manufacturer: Dell Computer Corporation
Product Name: PowerEdge 2550
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: Dell Computer Corporation
Type: Rack Mount Chassis
(zakaznik c.2)
DMI type 1, 25 bytes.
System Information
Manufacturer: Dell Computer Corporation
Product Name: PowerEdge 2650
--
DMI type 2, 9 bytes.
Base Board Information
Manufacturer: Dell Computer Corporation
Product Name: 0H3099
--
DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Dell Computer Corporation
Type: Rack Mount Chassis
(zakaznik c.3)
DMI type 1, 25 bytes.
System Information
Manufacturer: Dell Computer Corporation
Product Name: PowerEdge 2550
--
DMI type 3, 13 bytes.
Chassis Information
Manufacturer: Dell Computer Corporation
Type: Rack Mount Chassis
(zakaznuik c.4)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmi_strucs
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070227/af51ee2b/attachment-0001.pl
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (6 preceding siblings ...)
2007-02-27 20:41 ` Rudolf Marek
@ 2007-02-28 13:35 ` Hans de Goede
2007-02-28 13:44 ` Jasper Alias
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2007-02-28 13:35 UTC (permalink / raw)
To: lm-sensors
Rudolf Marek wrote:
> Hello Ivo,
>
> Back in the 2004 (12.06.2004 15:04 ;) I collected some DMI strings from
> different machines, please check the attachment for some summary and
> bellow for the 2004 raw data.
>
> Rudolf
>
Interesting stuff. Ivo, Gijs and Jasper. It looks like we need only need
to use the "Base Board" info from dmi, but also the "System info" as
some boards seem to fill "System info" with sensible info while filling
"Base Board" with less sensible info. I think this isn't hard todo, all
these fields are defined in the BIOS, and thus motherboard specific,
they should just all match, otherwise its a different motherboard.
(In case of changes because of BIOS updates we should be able to match
multiple DMI-table-entries to one motherboard-table-entry. Where with
table I mean database tables.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (7 preceding siblings ...)
2007-02-28 13:35 ` Hans de Goede
@ 2007-02-28 13:44 ` Jasper Alias
2007-03-01 7:46 ` Jean Delvare
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jasper Alias @ 2007-02-28 13:44 UTC (permalink / raw)
To: lm-sensors
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070228/159a643e/attachment.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (8 preceding siblings ...)
2007-02-28 13:44 ` Jasper Alias
@ 2007-03-01 7:46 ` Jean Delvare
2007-03-01 8:13 ` Hans de Goede
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-03-01 7:46 UTC (permalink / raw)
To: lm-sensors
Jasper, please don't send HTML-only e-mails to the lm-sensors list.
Jasper Alias wrote:
> Agreed we should be able to include both base info and
> system info into the system. Maybe we can check the values in
> those fields and then let the system decide with of the two
> contains the most sensible info and select that info field to
> be used.
It might be non-trivial to determine which fields contain relevant
information and which do not. If the fields are empty it's clear they
aren't relevant, but sometimes vendors put random crap in the fields
instead, such as "None" or "System Manufacturer" or "To Be Filled By
O.E.M.". Anyway, as Hans suggested, we don't really need to find out
which fields are most relevant. We can use all four fields as the key
to identify the motherboard, if parts of the key aren't meaningful it
doesn't really matter.
BTW, as the dmidecode maintainer, I have a lot of BIOS ROM images I use
for my regression tests. I can provide the system and board
manufacturer and product strings for all of them, to complement
Rudolf's list, if you are interested.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (9 preceding siblings ...)
2007-03-01 7:46 ` Jean Delvare
@ 2007-03-01 8:13 ` Hans de Goede
2007-03-01 8:54 ` Jean Delvare
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2007-03-01 8:13 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Jasper, please don't send HTML-only e-mails to the lm-sensors list.
>
> Jasper Alias wrote:
>> Agreed we should be able to include both base info and
>> system info into the system. Maybe we can check the values in
>> those fields and then let the system decide with of the two
>> contains the most sensible info and select that info field to
>> be used.
>
> It might be non-trivial to determine which fields contain relevant
> information and which do not. If the fields are empty it's clear they
> aren't relevant, but sometimes vendors put random crap in the fields
> instead, such as "None" or "System Manufacturer" or "To Be Filled By
> O.E.M.". Anyway, as Hans suggested, we don't really need to find out
> which fields are most relevant. We can use all four fields as the key
> to identify the motherboard, if parts of the key aren't meaningful it
> doesn't really matter.
>
Exactly, except when the whole key isn't relevant, iow all 4 Fields
contain crap / are to generic to uniquely identify a motherboard.
That is why we need a queue on the website for new motherboard dmi-info
+ lm-sensors-config submissions, and that queue needs to be checked
manually, we cannot expect well meaning end-users to make the decission
of the DMI info is unique enough. And on top of that a rating system
where people can say, good config works for me too, or crappy config
doesn't work.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (10 preceding siblings ...)
2007-03-01 8:13 ` Hans de Goede
@ 2007-03-01 8:54 ` Jean Delvare
2007-03-16 13:06 ` Ivo Manca
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-03-01 8:54 UTC (permalink / raw)
To: lm-sensors
Hi Hans,
On Thu, 01 Mar 2007 09:13:36 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > It might be non-trivial to determine which fields contain relevant
> > information and which do not. If the fields are empty it's clear they
> > aren't relevant, but sometimes vendors put random crap in the fields
> > instead, such as "None" or "System Manufacturer" or "To Be Filled By
> > O.E.M.". Anyway, as Hans suggested, we don't really need to find out
> > which fields are most relevant. We can use all four fields as the key
> > to identify the motherboard, if parts of the key aren't meaningful it
> > doesn't really matter.
>
> Exactly, except when the whole key isn't relevant, iow all 4 Fields
> contain crap / are to generic to uniquely identify a motherboard.
True, this kind of board exists :(
> That is why we need a queue on the website for new motherboard dmi-info
> + lm-sensors-config submissions, and that queue needs to be checked
> manually, we cannot expect well meaning end-users to make the decission
> of the DMI info is unique enough. And on top of that a rating system
> where people can say, good config works for me too, or crappy config
> doesn't work.
Another approach is to let the submissions go through but in an
"unconfirmed" state. If two unconfirmed sumbissions have the same DMI
signature but list different drivers, we demote them to state "bogus"
or something similar.
Anyway, I don't really care about the exact implementation, it's up to
your students. Now that they are aware that the DMI data might not be
100% reliable, I'm certain they'll come up with a solution.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (11 preceding siblings ...)
2007-03-01 8:54 ` Jean Delvare
@ 2007-03-16 13:06 ` Ivo Manca
2007-03-18 20:29 ` Jean Delvare
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Ivo Manca @ 2007-03-16 13:06 UTC (permalink / raw)
To: lm-sensors
Hey Jean,
Just a few more questions from our side ;).
First of all, is it good idea to scan for sensors in the CPU's after our
script successfully finds a match with the DMI information?
If we don't do this, the user might have a disadvantage using the new way of
detection, since the DMI information will only used be for mainboard
information.
However, we are not completely sure if the CPU detection is currently
completely safe. Do you have any idea about that? Because if it isn't, it
might not be a good idea to "just" let that also run.
Secondly, do you prefer using the local database (/cache, which contains the
dmi-info versus configuration) as the default option, or to prefer it when
the default option fetching the online database first?
Downloading the online database is a big pro, since faulty and new
configurations can be fixed and updated.
Just wondering what you think about it.
You were also saying that you could provided quite some more DMI strings to
complement the list Rudolf send earlier. Could you please do that? Would be
nice to find out about strange exceptions in an early stage ;).
Thanks in advance,
Ivo Manca
Gijs van der Weg
Jasper Alias
----- Original Message -----
From: "Jean Delvare" <khali at linux-fr.org>
To: "Hans de Goede" <j.w.r.degoede at hhs.nl>
Cc: <lm-sensors at lm-sensors.org>
Sent: Thursday 1 March 2007 9:54
Subject: Re: [lm-sensors] Sensors-detect with DMI detection
> Hi Hans,
>
> On Thu, 01 Mar 2007 09:13:36 +0100, Hans de Goede wrote:
>> Jean Delvare wrote:
>> > It might be non-trivial to determine which fields contain relevant
>> > information and which do not. If the fields are empty it's clear they
>> > aren't relevant, but sometimes vendors put random crap in the fields
>> > instead, such as "None" or "System Manufacturer" or "To Be Filled By
>> > O.E.M.". Anyway, as Hans suggested, we don't really need to find out
>> > which fields are most relevant. We can use all four fields as the key
>> > to identify the motherboard, if parts of the key aren't meaningful it
>> > doesn't really matter.
>>
>> Exactly, except when the whole key isn't relevant, iow all 4 Fields
>> contain crap / are to generic to uniquely identify a motherboard.
>
> True, this kind of board exists :(
>
>> That is why we need a queue on the website for new motherboard dmi-info
>> + lm-sensors-config submissions, and that queue needs to be checked
>> manually, we cannot expect well meaning end-users to make the decission
>> of the DMI info is unique enough. And on top of that a rating system
>> where people can say, good config works for me too, or crappy config
>> doesn't work.
>
> Another approach is to let the submissions go through but in an
> "unconfirmed" state. If two unconfirmed sumbissions have the same DMI
> signature but list different drivers, we demote them to state "bogus"
> or something similar.
>
> Anyway, I don't really care about the exact implementation, it's up to
> your students. Now that they are aware that the DMI data might not be
> 100% reliable, I'm certain they'll come up with a solution.
>
> --
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (12 preceding siblings ...)
2007-03-16 13:06 ` Ivo Manca
@ 2007-03-18 20:29 ` Jean Delvare
2007-03-20 12:39 ` Ivo Manca
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-03-18 20:29 UTC (permalink / raw)
To: lm-sensors
Hi Ivo,
On Fri, 16 Mar 2007 14:06:08 +0100, Ivo Manca wrote:
> First of all, is it good idea to scan for sensors in the CPU's after our
> script successfully finds a match with the DMI information?
> If we don't do this, the user might have a disadvantage using the new way of
> detection, since the DMI information will only used be for mainboard
> information.
> However, we are not completely sure if the CPU detection is currently
> completely safe. Do you have any idea about that? Because if it isn't, it
> might not be a good idea to "just" let that also run.
This is a good point. DMI data is indeed mainly about the motherboard,
while sensors can be found in other parts of the computer: CPU as you
found yourself, but also graphics adapter, memory module or hard disk
drive (not yet supported by lm-sensors.) The DMI database you're
working on can obviously only cover the motherboard sensors.
The current detection of CPU-embedded sensors is totally safe. It's
not based on physical probing as is the case for SMBus or Super-I/O
hardware monitoring chips. Instead, it is based on the presence of a
given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
include that part of sensors-detect in conjunction with your DMI-based
identification for the motherboard sensors.
Note that PCI drivers can be automatically loaded, so we could even
stop handling them in sensors-detect. We leave them in for
completeness, but chances are that the driver will already be loaded
before the user runs sensors-detect (assuming the required driver is
available on the system, of course.)
> Secondly, do you prefer using the local database (/cache, which contains the
> dmi-info versus configuration) as the default option, or to prefer it when
> the default option fetching the online database first?
>
> Downloading the online database is a big pro, since faulty and new
> configurations can be fixed and updated.
>
> Just wondering what you think about it.
Good point again. Using the local database first will lower the load on
our server significantly, and will be overall faster for the user.
Missing configurations that were added later to the online database are
not a problem, we obviously want to try the online database if the
local cache has no information. The case where the configuration file
was updated is admittedly more problematic. I wonder how frequently the
configurations will be updated in practice. It's hard to predict.
I'm not too sure, but I'd say use the online database first, and
fallback to the cache if network is not available OR if the user
doesn't want the script to connect (a command-line option would be
welcome.)
> You were also saying that you could provided quite some more DMI strings to
> complement the list Rudolf send earlier. Could you please do that? Would be
> nice to find out about strange exceptions in an early stage ;).
OK, I will extract the info and send it to you in private tomorrow.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (13 preceding siblings ...)
2007-03-18 20:29 ` Jean Delvare
@ 2007-03-20 12:39 ` Ivo Manca
2007-03-22 10:09 ` Ivo Manca
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Ivo Manca @ 2007-03-20 12:39 UTC (permalink / raw)
To: lm-sensors
Hey Jean,
> This is a good point. DMI data is indeed mainly about the motherboard,
> while sensors can be found in other parts of the computer: CPU as you
> found yourself, but also graphics adapter, memory module or hard disk
> drive (not yet supported by lm-sensors.) The DMI database you're
> working on can obviously only cover the motherboard sensors.
We were aware about these situaties. But since the harddisk and videocard
sensors are found by probing, we'd rather not do anything with them. Because
we figured out the CPU detection might be safe, we considered that option as
well.
> The current detection of CPU-embedded sensors is totally safe. It's
> not based on physical probing as is the case for SMBus or Super-I/O
> hardware monitoring chips. Instead, it is based on the presence of a
> given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
> include that part of sensors-detect in conjunction with your DMI-based
> identification for the motherboard sensors.
That sounds good! Must be easy to call the cpu detection after the DMI
probing has succeeded :).
> Note that PCI drivers can be automatically loaded, so we could even
> stop handling them in sensors-detect. We leave them in for
> completeness, but chances are that the driver will already be loaded
> before the user runs sensors-detect (assuming the required driver is
> available on the system, of course.)
Noted
> Good point again. Using the local database first will lower the load on
> our server significantly, and will be overall faster for the user.
> Missing configurations that were added later to the online database are
> not a problem, we obviously want to try the online database if the
> local cache has no information. The case where the configuration file
> was updated is admittedly more problematic. I wonder how frequently the
> configurations will be updated in practice. It's hard to predict.
>
> I'm not too sure, but I'd say use the online database first, and
> fallback to the cache if network is not available OR if the user
> doesn't want the script to connect (a command-line option would be
> welcome.)
Noted, and the user will ofcourse be noticed. A commandline option for
dissabling it (or just _only_ updating the cache without doing anything
else) will be added.
>> You were also saying that you could provided quite some more DMI strings
>> to
>> complement the list Rudolf send earlier. Could you please do that? Would
>> be
>> nice to find out about strange exceptions in an early stage ;).
>
> OK, I will extract the info and send it to you in private tomorrow.
>
> --
> Jean Delvare
I received them, thank you!
Ivo Manca
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (14 preceding siblings ...)
2007-03-20 12:39 ` Ivo Manca
@ 2007-03-22 10:09 ` Ivo Manca
2007-03-23 8:59 ` Jean Delvare
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Ivo Manca @ 2007-03-22 10:09 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
Just a quick question (again ;)). Is it necesary for us to even think about
supporting the 2.4 kernels?
I'm asking this, because if our addition doesn't get included before
libsensors 3.x, it seems like we only get to work with 2.6, isn't it?
If that is so, we can drop a table in our database. This is because we want
to add the kernel versions a configuration is working for. The easiest way
to implement this, is to just modify the minimum kernel version for that
configuration. If there's no support for 2.4, we can just add a field with
the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also
register the minimum 2.4 version, either as a field, or with a
table/relationship.
Just wondering :)
Ivo Manca
Jasper Alias
Gijs van der Weg
----- Original Message -----
From: "Jean Delvare" <khali at linux-fr.org>
To: "Ivo Manca" <pinkel at gmail.com>
Cc: "Hans de Goede" <j.w.r.degoede at hhs.nl>; <lm-sensors at lm-sensors.org>
Sent: Sunday 18 March 2007 21:29
Subject: Re: [lm-sensors] Sensors-detect with DMI detection
> Hi Ivo,
>
> On Fri, 16 Mar 2007 14:06:08 +0100, Ivo Manca wrote:
>> First of all, is it good idea to scan for sensors in the CPU's after our
>> script successfully finds a match with the DMI information?
>> If we don't do this, the user might have a disadvantage using the new way
>> of
>> detection, since the DMI information will only used be for mainboard
>> information.
>> However, we are not completely sure if the CPU detection is currently
>> completely safe. Do you have any idea about that? Because if it isn't, it
>> might not be a good idea to "just" let that also run.
>
> This is a good point. DMI data is indeed mainly about the motherboard,
> while sensors can be found in other parts of the computer: CPU as you
> found yourself, but also graphics adapter, memory module or hard disk
> drive (not yet supported by lm-sensors.) The DMI database you're
> working on can obviously only cover the motherboard sensors.
>
> The current detection of CPU-embedded sensors is totally safe. It's
> not based on physical probing as is the case for SMBus or Super-I/O
> hardware monitoring chips. Instead, it is based on the presence of a
> given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
> include that part of sensors-detect in conjunction with your DMI-based
> identification for the motherboard sensors.
>
> Note that PCI drivers can be automatically loaded, so we could even
> stop handling them in sensors-detect. We leave them in for
> completeness, but chances are that the driver will already be loaded
> before the user runs sensors-detect (assuming the required driver is
> available on the system, of course.)
>
>> Secondly, do you prefer using the local database (/cache, which contains
>> the
>> dmi-info versus configuration) as the default option, or to prefer it
>> when
>> the default option fetching the online database first?
>>
>> Downloading the online database is a big pro, since faulty and new
>> configurations can be fixed and updated.
>>
>> Just wondering what you think about it.
>
> Good point again. Using the local database first will lower the load on
> our server significantly, and will be overall faster for the user.
> Missing configurations that were added later to the online database are
> not a problem, we obviously want to try the online database if the
> local cache has no information. The case where the configuration file
> was updated is admittedly more problematic. I wonder how frequently the
> configurations will be updated in practice. It's hard to predict.
>
> I'm not too sure, but I'd say use the online database first, and
> fallback to the cache if network is not available OR if the user
> doesn't want the script to connect (a command-line option would be
> welcome.)
>
>> You were also saying that you could provided quite some more DMI strings
>> to
>> complement the list Rudolf send earlier. Could you please do that? Would
>> be
>> nice to find out about strange exceptions in an early stage ;).
>
> OK, I will extract the info and send it to you in private tomorrow.
>
> --
> Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (15 preceding siblings ...)
2007-03-22 10:09 ` Ivo Manca
@ 2007-03-23 8:59 ` Jean Delvare
2007-03-23 9:06 ` Hans de Goede
2007-03-23 15:43 ` Jean Delvare
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-03-23 8:59 UTC (permalink / raw)
To: lm-sensors
Hi Ivo,
On Thu, 22 Mar 2007 11:09:14 +0100, Ivo Manca wrote:
> Just a quick question (again ;)). Is it necesary for us to even think about
> supporting the 2.4 kernels?
> I'm asking this, because if our addition doesn't get included before
> libsensors 3.x, it seems like we only get to work with 2.6, isn't it?
Side note: we are already at libsensors 3.x (unfortunately.) What you
refer to is lm-sensors 3.x, for which the libsensors version will be
4.x. Actually I think we should jump to lm-sensors 4.x directly to sync
the lib version with the package version again - but Mark seems to like
lm-sensors 3.x.
> If that is so, we can drop a table in our database. This is because we want
> to add the kernel versions a configuration is working for. The easiest way
> to implement this, is to just modify the minimum kernel version for that
> configuration. If there's no support for 2.4, we can just add a field with
> the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also
> register the minimum 2.4 version, either as a field, or with a
> table/relationship.
>
> Just wondering :)
We don't really care about 2.4 anymore. If you can support it for free,
alright. If it has a cost, just don't do it.
One thing which you will have to handle though are the syntax changes
to sensors.conf. Two things are going to happen in a (more or less)
near future:
* Mark Hoffman will add support for the "include" statement. Obviously,
the user will need libsensors 4.x if they download a configuration file
which uses such a statement. OTOH, I can't see any reason why an
include statement would be used in the configuration files for
motherboards, so maybe all you have to do is strip any include
statement before storing the configuration file in the database.
* Once the library discovers the device features autmatically,
sensors.conf will have to use the standard feature names, instead of
the custom ones. This means we'll have to fork sensors.conf.eg into an
old-style version and a new-style version. The configuration files
stored in your database will have the same problem - they will work
with either the old library, or the new one, but not both.
Note that it should be possible to translate old-style configuration
files to the new style automatically, using the same translation
rules which are used by libsensors today. A perl script would do. The
other way around is much more difficult, though, as you would need to
write an extensive reverse mapping table for every supported chip.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (16 preceding siblings ...)
2007-03-23 8:59 ` Jean Delvare
@ 2007-03-23 9:06 ` Hans de Goede
2007-03-23 15:43 ` Jean Delvare
18 siblings, 0 replies; 20+ messages in thread
From: Hans de Goede @ 2007-03-23 9:06 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Hi Ivo,
>
> On Thu, 22 Mar 2007 11:09:14 +0100, Ivo Manca wrote:
>> Just a quick question (again ;)). Is it necesary for us to even think about
>> supporting the 2.4 kernels?
>> I'm asking this, because if our addition doesn't get included before
>> libsensors 3.x, it seems like we only get to work with 2.6, isn't it?
>
> Side note: we are already at libsensors 3.x (unfortunately.) What you
> refer to is lm-sensors 3.x, for which the libsensors version will be
> 4.x. Actually I think we should jump to lm-sensors 4.x directly to sync
> the lib version with the package version again - but Mark seems to like
> lm-sensors 3.x.
>
>> If that is so, we can drop a table in our database. This is because we want
>> to add the kernel versions a configuration is working for. The easiest way
>> to implement this, is to just modify the minimum kernel version for that
>> configuration. If there's no support for 2.4, we can just add a field with
>> the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also
>> register the minimum 2.4 version, either as a field, or with a
>> table/relationship.
>>
>> Just wondering :)
>
> We don't really care about 2.4 anymore. If you can support it for free,
> alright. If it has a cost, just don't do it.
>
> One thing which you will have to handle though are the syntax changes
> to sensors.conf. Two things are going to happen in a (more or less)
> near future:
>
> * Mark Hoffman will add support for the "include" statement. Obviously,
> the user will need libsensors 4.x if they download a configuration file
> which uses such a statement. OTOH, I can't see any reason why an
> include statement would be used in the configuration files for
> motherboards, so maybe all you have to do is strip any include
> statement before storing the configuration file in the database.
>
> * Once the library discovers the device features autmatically,
> sensors.conf will have to use the standard feature names, instead of
> the custom ones. This means we'll have to fork sensors.conf.eg into an
> old-style version and a new-style version. The configuration files
> stored in your database will have the same problem - they will work
> with either the old library, or the new one, but not both.
>
> Note that it should be possible to translate old-style configuration
> files to the new style automatically, using the same translation
> rules which are used by libsensors today. A perl script would do. The
> other way around is much more difficult, though, as you would need to
> write an extensive reverse mapping table for every supported chip.
>
Wouldn't it be wise to target only 3.x / 4.x with the dmi-detect code, and thus
assume dynamic chip support and the new syntax? I haven't been doing much
lm-sensors related work myself lately, but I can make some time free to get the
dyn chip support into the 3.0 branch asap, if that helps the dmi detect code to
become future proof. I think only support 3.x / 4.x is easiest / best otherwise
the code becomes convoluted with compatibility muck from the day it was written.
Regards,
Hans
^ permalink raw reply [flat|nested] 20+ messages in thread
* [lm-sensors] Sensors-detect with DMI detection
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
` (17 preceding siblings ...)
2007-03-23 9:06 ` Hans de Goede
@ 2007-03-23 15:43 ` Jean Delvare
18 siblings, 0 replies; 20+ messages in thread
From: Jean Delvare @ 2007-03-23 15:43 UTC (permalink / raw)
To: lm-sensors
Hi Hans,
On Fri, 23 Mar 2007 10:06:10 +0100, Hans de Goede wrote:
> Wouldn't it be wise to target only 3.x / 4.x with the dmi-detect code, and thus
> assume dynamic chip support and the new syntax? I haven't been doing much
> lm-sensors related work myself lately, but I can make some time free to get the
> dyn chip support into the 3.0 branch asap, if that helps the dmi detect code to
> become future proof. I think only support 3.x / 4.x is easiest / best otherwise
> the code becomes convoluted with compatibility muck from the day it was written.
I tend to agree, yeah. The only problem is that I cannot give any
timeline for the dyn chip support, as I do not have the time to work on
it myself. But if you're going to do it, alright.
--
Jean Delvare
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2007-03-23 15:43 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-22 14:40 [lm-sensors] Sensors-detect with DMI detection Ivo Manca
2007-02-22 17:19 ` Jean Delvare
2007-02-23 7:08 ` Hans de Goede
2007-02-27 8:50 ` Jean Delvare
2007-02-27 10:59 ` Ivo Manca
2007-02-27 11:43 ` Jean Delvare
2007-02-27 12:24 ` Ivo Manca
2007-02-27 20:41 ` Rudolf Marek
2007-02-28 13:35 ` Hans de Goede
2007-02-28 13:44 ` Jasper Alias
2007-03-01 7:46 ` Jean Delvare
2007-03-01 8:13 ` Hans de Goede
2007-03-01 8:54 ` Jean Delvare
2007-03-16 13:06 ` Ivo Manca
2007-03-18 20:29 ` Jean Delvare
2007-03-20 12:39 ` Ivo Manca
2007-03-22 10:09 ` Ivo Manca
2007-03-23 8:59 ` Jean Delvare
2007-03-23 9:06 ` Hans de Goede
2007-03-23 15:43 ` Jean Delvare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.