* Re: [lm-sensors] Another possible hwmon project
2009-06-24 8:17 [lm-sensors] Another possible hwmon project Andre Prendel
@ 2009-06-24 8:24 ` Hans de Goede
2009-06-24 9:26 ` Andre Prendel
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Hans de Goede @ 2009-06-24 8:24 UTC (permalink / raw)
To: lm-sensors
Hi all,
On 06/24/2009 10:17 AM, Andre Prendel wrote:
> On Mon, Jun 22, 2009 at 12:03:13AM +0200, Hans de Goede wrote:
>>
>> On 06/21/2009 10:35 AM, Andre Prendel wrote:
>>> On Fri, Jun 19, 2009 at 09:15:39AM +0200, Hans de Goede wrote:
>>>> Hi,
>>> Hi Hans,
>>>
>>> First, sorry for bad response times. I'm very busy with private stuff
>>> at the moment. I'll change the company I'm working for. This is
>>> related with moving back to my hometown (Dresden).
>>>
>> Ok, np.
>>
>>>> <snip>
>>>>
>>>>> Thanks for all the material. I read some stuff about DMI and SMBIOS
>>>>> yesterday. Further I checked out the dmidecode source code. I will
>>>>> go on with investigation by reading the mailing list discussions etc.
>>>>>
>>>> I don't think you need to dig that deep wrt DMI,
>>> I want to know how things work at low level. This makes things easier
>>> to understand for me.
>>>
>>>> what we will most likely
>>>> and up doing is looking for the strings found inside
>>>> /sys/devices/virtual/dmi/id/board_name
>>>> /sys/devices/virtual/dmi/id/board_vendor
>>> I can't see these files in sysfs. What driver is responsible for creation?
>>>
>> Hmm, strange, I dunno on all my systems they just exists. Weird, maybe you
>> are running a somewhat old kernel ?
>
> Ok, I've found the files on my system under /sys/class/dmi/id/. Driver
> /drivers/firmware/dmi-id.c creates the files. The driver was
> introduced in 2007.
>
Hmm, ok, I have them there too (/sys/class/dmi/id is a symlink to
/sys/devices/virtual/dmi/id on my system), so if /sys/class/dmi/id
works on more systems / kernel configs lets use that.
> Jean, could you bring some light into the darkness? I've seen you did
> some work on the DMI stuff.
>
> I'm using the most recent mainline kernel form git. Hans, what version
> do you use?
>
I'm using a stock Fedora 11 kernel, I think this might be related to
the various sysfs compatibility kernel configuration options.
> BTW, Jean. Hans asked me for working on the automatic configuration of
> sensors using DMI information.
>
Ack, its still something which I would like to see done, so I suggested the
idea to Andre.
Andre, as said before I think once you're done orienting yourself, the first
thing to do is write a proposal how this all will work and send it to the
list.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [lm-sensors] Another possible hwmon project
2009-06-24 8:17 [lm-sensors] Another possible hwmon project Andre Prendel
2009-06-24 8:24 ` Hans de Goede
@ 2009-06-24 9:26 ` Andre Prendel
2009-06-26 8:29 ` Andre Prendel
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Andre Prendel @ 2009-06-24 9:26 UTC (permalink / raw)
To: lm-sensors
D'oh! Forgot to CC Jean.
On Mon, Jun 22, 2009 at 12:03:13AM +0200, Hans de Goede wrote:
>
>
> On 06/21/2009 10:35 AM, Andre Prendel wrote:
>> On Fri, Jun 19, 2009 at 09:15:39AM +0200, Hans de Goede wrote:
>>> Hi,
>>
>> Hi Hans,
>>
>> First, sorry for bad response times. I'm very busy with private stuff
>> at the moment. I'll change the company I'm working for. This is
>> related with moving back to my hometown (Dresden).
>>
>
> Ok, np.
>
>>>
>>> <snip>
>>>
>>>> Thanks for all the material. I read some stuff about DMI and SMBIOS
>>>> yesterday. Further I checked out the dmidecode source code. I will
>>>> go on with investigation by reading the mailing list discussions etc.
>>>>
>>> I don't think you need to dig that deep wrt DMI,
>>
>> I want to know how things work at low level. This makes things easier
>> to understand for me.
>>
>>> what we will most likely
>>> and up doing is looking for the strings found inside
>>> /sys/devices/virtual/dmi/id/board_name
>>> /sys/devices/virtual/dmi/id/board_vendor
>>
>> I can't see these files in sysfs. What driver is responsible for creation?
>>
>
> Hmm, strange, I dunno on all my systems they just exists. Weird, maybe you
> are running a somewhat old kernel ?
Ok, I've found the files on my system under /sys/class/dmi/id/. Driver
/drivers/firmware/dmi-id.c creates the files. The driver was
introduced in 2007.
Jean, could you bring some light into the darkness? I've seen you did
some work on the DMI stuff.
I'm using the most recent mainline kernel form git. Hans, what version
do you use?
BTW, Jean. Hans asked me for working on the automatic configuration of
sensors using DMI information.
>>> Which contain the DMI info in 100% ready for use fashion (as
>>> plain ASCII strings)
>>>
>
> Regards,
>
> Hans
Thanks,
Andre
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [lm-sensors] Another possible hwmon project
2009-06-24 8:17 [lm-sensors] Another possible hwmon project Andre Prendel
2009-06-24 8:24 ` Hans de Goede
2009-06-24 9:26 ` Andre Prendel
@ 2009-06-26 8:29 ` Andre Prendel
2009-07-21 14:20 ` Jean Delvare
2009-07-22 20:44 ` Andre Prendel
4 siblings, 0 replies; 6+ messages in thread
From: Andre Prendel @ 2009-06-26 8:29 UTC (permalink / raw)
To: lm-sensors
On Wed, Jun 24, 2009 at 10:24:03AM +0200, Hans de Goede wrote:
<snip>
> >>>> I don't think you need to dig that deep wrt DMI,
> >>> I want to know how things work at low level. This makes things easier
> >>> to understand for me.
> >>>
> >>>> what we will most likely
> >>>> and up doing is looking for the strings found inside
> >>>> /sys/devices/virtual/dmi/id/board_name
> >>>> /sys/devices/virtual/dmi/id/board_vendor
> >>> I can't see these files in sysfs. What driver is responsible for creation?
> >>>
> >> Hmm, strange, I dunno on all my systems they just exists. Weird, maybe you
> >> are running a somewhat old kernel ?
> >
> > Ok, I've found the files on my system under /sys/class/dmi/id/. Driver
> > /drivers/firmware/dmi-id.c creates the files. The driver was
> > introduced in 2007.
> >
>
> Hmm, ok, I have them there too (/sys/class/dmi/id is a symlink to
> /sys/devices/virtual/dmi/id on my system), so if /sys/class/dmi/id
> works on more systems / kernel configs lets use that.
Ok, that's a known issue. Sensors-detect already take care of it.
---
r5530 | khali | 2008-12-05 23:56:30 +0100 (Fr, 05. Dez 2008) | 3 lines
Alternatively look for DMI data in /sys/class/dmi/id, as
/sys/devices/virtual/dmi/id only exists since kernel 2.6.28.
Index: prog/detect/sensors-detect
=================================--- prog/detect/sensors-detect (Revision 5529)
+++ prog/detect/sensors-detect (Revision 5530)
@@ -2150,11 +2150,13 @@
'System Manufacturer' => 1,
'System Name' => 1,
);
+ my $dmi_id_dir;
# First try reading the strings from sysfs if available
- if (-d "$sysfs_root/devices/virtual/dmi/id") {
+ if (-d ($dmi_id_dir = "$sysfs_root/devices/virtual/dmi/id") # kernel >= 2.6.28
+ || -d ($dmi_id_dir = "$sysfs_root/class/dmi/id")) {
foreach my $k (keys %items) {
- $dmi{$k} = sysfs_device_attribute("$sysfs_root/devices/virtual/dmi/id", $k);
+ $dmi{$k} = sysfs_device_attribute($dmi_id_dir, $k);
}
} else {
# Else fallback on calling dmidecode
---
Looking for both should be the best.
> > Jean, could you bring some light into the darkness? I've seen you did
> > some work on the DMI stuff.
> >
> > I'm using the most recent mainline kernel form git. Hans, what version
> > do you use?
> >
>
> I'm using a stock Fedora 11 kernel, I think this might be related to
> the various sysfs compatibility kernel configuration options.
>
> > BTW, Jean. Hans asked me for working on the automatic configuration of
> > sensors using DMI information.
> >
>
> Ack, its still something which I would like to see done, so I suggested the
> idea to Andre.
>
> Andre, as said before I think once you're done orienting yourself, the first
> thing to do is write a proposal how this all will work and send it to the
> list.
>
> Regards,
>
> Hans
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [lm-sensors] Another possible hwmon project
2009-06-24 8:17 [lm-sensors] Another possible hwmon project Andre Prendel
` (2 preceding siblings ...)
2009-06-26 8:29 ` Andre Prendel
@ 2009-07-21 14:20 ` Jean Delvare
2009-07-22 20:44 ` Andre Prendel
4 siblings, 0 replies; 6+ messages in thread
From: Jean Delvare @ 2009-07-21 14:20 UTC (permalink / raw)
To: lm-sensors
Hi Andre, Hans,
Sorry again for the late answer. I'm taking benefit of my forced
off-line time to answer my old e-mail.
On Fri, 26 Jun 2009 10:29:33 +0200, Andre Prendel wrote:
> Ok, that's a known issue. Sensors-detect already take care of it.
>
> ---
> r5530 | khali | 2008-12-05 23:56:30 +0100 (Fr, 05. Dez 2008) | 3 lines
>
> Alternatively look for DMI data in /sys/class/dmi/id, as
> /sys/devices/virtual/dmi/id only exists since kernel 2.6.28.
>
> Index: prog/detect/sensors-detect
> =================================> --- prog/detect/sensors-detect (Revision 5529)
> +++ prog/detect/sensors-detect (Revision 5530)
> @@ -2150,11 +2150,13 @@
> 'System Manufacturer' => 1,
> 'System Name' => 1,
> );
> + my $dmi_id_dir;
>
> # First try reading the strings from sysfs if available
> - if (-d "$sysfs_root/devices/virtual/dmi/id") {
> + if (-d ($dmi_id_dir = "$sysfs_root/devices/virtual/dmi/id") # kernel >= 2.6.28
> + || -d ($dmi_id_dir = "$sysfs_root/class/dmi/id")) {
> foreach my $k (keys %items) {
> - $dmi{$k} = sysfs_device_attribute("$sysfs_root/devices/virtual/dmi/id", $k);
> + $dmi{$k} = sysfs_device_attribute($dmi_id_dir, $k);
> }
> } else {
> # Else fallback on calling dmidecode
> ---
>
> Looking for both should be the best.
Indeed, I had hit the problem before, and solved it with the above
patch. BTW, I do not think Andre will have too much work with the
DMI/SMBIOS part, because what's already in sensors-detect should be
good enough. We can discuss which strings exactly we want to use,
whether we want to clean them up and how, how to encode them etc. but
the fetching part should be robust by now.
Actually, I added DMI identification to sensors-detect with in mind the
idea of leveraging it for automatic configuration, just as Hans was
mentioning (and as was already discussed on the list in the past.) I am
not sure whether sensors-detect would be used for that, or a separate
script/tool, but at least the logic and possibly the code for the
DMI-based board identification should be reusable.
> > > BTW, Jean. Hans asked me for working on the automatic configuration of
> > > sensors using DMI information.
> >
> > Ack, its still something which I would like to see done, so I suggested the
> > idea to Andre.
I also do think this should be done. My plan a few months ago was to
spend Novell's Hack Week IV on it, but it had to happen that this week
is the week I'm moving to a new flat, which means a few days without
easy Internet access, plus all the furniture to move around. So it was
definitely not the right week. But we can work on this together at any
later point anyway.
Slightly more into the details, my plan was a two-step one:
1* Come up with a filesystem-based storage structure for board-specific
configuration files. For example:
/usr/share/sensors/conf/dmi/by-board/$vendor/$board.conf
/usr/share/sensors/conf/dmi/by-product/$vendor/$product.conf
And add the logic to sensors-detect (or another script, this can be
debated) to check for this file and propose to copy the
configuration file to /etc/sensors.d.
2* Come up with a network-based storage structure for the same files.
I am not going into the details here, this would be done later
anyway and I have no precise idea of how to implement (and host) the
service. There might be something about this in the document that
was written by Jasper Alias, Ivo Manca and Gijs van der Weg back in
February 2007 *sigh* which I admit I never read *re-sigh*.
Andre, if you did not receive a copy of this document already, I can
send it to you.
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [lm-sensors] Another possible hwmon project
2009-06-24 8:17 [lm-sensors] Another possible hwmon project Andre Prendel
` (3 preceding siblings ...)
2009-07-21 14:20 ` Jean Delvare
@ 2009-07-22 20:44 ` Andre Prendel
4 siblings, 0 replies; 6+ messages in thread
From: Andre Prendel @ 2009-07-22 20:44 UTC (permalink / raw)
To: lm-sensors
On Tue, Jul 21, 2009 at 04:20:20PM +0200, Jean Delvare wrote:
> Hi Andre, Hans,
Hey you two,
> Sorry again for the late answer. I'm taking benefit of my forced
> off-line time to answer my old e-mail.
>
> On Fri, 26 Jun 2009 10:29:33 +0200, Andre Prendel wrote:
> > Ok, that's a known issue. Sensors-detect already take care of it.
> >
> > ---
> > r5530 | khali | 2008-12-05 23:56:30 +0100 (Fr, 05. Dez 2008) | 3 lines
> >
> > Alternatively look for DMI data in /sys/class/dmi/id, as
> > /sys/devices/virtual/dmi/id only exists since kernel 2.6.28.
> >
> > Index: prog/detect/sensors-detect
> > =================================> > --- prog/detect/sensors-detect (Revision 5529)
> > +++ prog/detect/sensors-detect (Revision 5530)
> > @@ -2150,11 +2150,13 @@
> > 'System Manufacturer' => 1,
> > 'System Name' => 1,
> > );
> > + my $dmi_id_dir;
> >
> > # First try reading the strings from sysfs if available
> > - if (-d "$sysfs_root/devices/virtual/dmi/id") {
> > + if (-d ($dmi_id_dir = "$sysfs_root/devices/virtual/dmi/id") # kernel >= 2.6.28
> > + || -d ($dmi_id_dir = "$sysfs_root/class/dmi/id")) {
> > foreach my $k (keys %items) {
> > - $dmi{$k} = sysfs_device_attribute("$sysfs_root/devices/virtual/dmi/id", $k);
> > + $dmi{$k} = sysfs_device_attribute($dmi_id_dir, $k);
> > }
> > } else {
> > # Else fallback on calling dmidecode
> > ---
> >
> > Looking for both should be the best.
>
> Indeed, I had hit the problem before, and solved it with the above
> patch. BTW, I do not think Andre will have too much work with the
> DMI/SMBIOS part, because what's already in sensors-detect should be
> good enough. We can discuss which strings exactly we want to use,
> whether we want to clean them up and how, how to encode them etc. but
> the fetching part should be robust by now.
>
> Actually, I added DMI identification to sensors-detect with in mind the
> idea of leveraging it for automatic configuration, just as Hans was
> mentioning (and as was already discussed on the list in the past.) I am
> not sure whether sensors-detect would be used for that, or a separate
> script/tool, but at least the logic and possibly the code for the
> DMI-based board identification should be reusable.
>
> > > > BTW, Jean. Hans asked me for working on the automatic configuration of
> > > > sensors using DMI information.
> > >
> > > Ack, its still something which I would like to see done, so I suggested the
> > > idea to Andre.
>
> I also do think this should be done. My plan a few months ago was to
> spend Novell's Hack Week IV on it, but it had to happen that this week
> is the week I'm moving to a new flat, which means a few days without
> easy Internet access, plus all the furniture to move around. So it was
> definitely not the right week. But we can work on this together at any
> later point anyway.
>
> Slightly more into the details, my plan was a two-step one:
>
> 1* Come up with a filesystem-based storage structure for board-specific
> configuration files. For example:
>
> /usr/share/sensors/conf/dmi/by-board/$vendor/$board.conf
> /usr/share/sensors/conf/dmi/by-product/$vendor/$product.conf
>
> And add the logic to sensors-detect (or another script, this can be
> debated) to check for this file and propose to copy the
> configuration file to /etc/sensors.d.
>
> 2* Come up with a network-based storage structure for the same files.
> I am not going into the details here, this would be done later
> anyway and I have no precise idea of how to implement (and host) the
> service. There might be something about this in the document that
> was written by Jasper Alias, Ivo Manca and Gijs van der Weg back in
> February 2007 *sigh* which I admit I never read *re-sigh*.
> Andre, if you did not receive a copy of this document already, I can
> send it to you.
Unfortunately I'm very busy with my new job (have to explore tons of
c++ code), so I didn't find the time to do some work on this. I didn't
even read all the mailings to this topic. Hans already sent all the
stuff to me. I hope I can find some time at the weekend to make some
thoughts, gather all the information and maybe start another DMI
Config thread :)
>
> Thanks,
> --
> Jean Delvare
Thanks,
Andre
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 6+ messages in thread