All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Motherboard-specific configurations (sensors4mobo)
Date: Thu, 29 Mar 2007 14:56:16 +0000	[thread overview]
Message-ID: <460BD390.5000407@hhs.nl> (raw)
In-Reply-To: <46084A44.4070101@eberian.com>

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

  parent reply	other threads:[~2007-03-29 14:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-26 22:33 [lm-sensors] Motherboard-specific configurations (sensors4mobo) Ed Lucas
2007-03-27 15:39 ` Jean Delvare
2007-03-27 16:07 ` Ivo Manca
2007-03-28  9:30 ` Ed Lucas
2007-03-28 10:56 ` Ivo Manca
2007-03-28 11:20 ` Hans de Goede
2007-03-28 11:49 ` Ed Lucas
2007-03-28 12:07 ` Ivo Manca
2007-03-28 17:09 ` David Hubbard
2007-03-29  8:03 ` Pinkel
2007-03-29 10:00 ` Ed Lucas
2007-03-29 13:20 ` Ivo Manca
2007-03-29 14:18 ` Ed Lucas
2007-03-29 14:56 ` Hans de Goede [this message]
2007-03-31 12:22 ` Jean Delvare
2007-03-31 12:36 ` Jean Delvare
2007-03-31 12:42 ` Jean Delvare
2007-03-31 12:45 ` Jean Delvare
2007-03-31 12:50 ` Jean Delvare
2007-04-04  9:34 ` Ivo Manca
2007-04-08 11:13 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=460BD390.5000407@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.