From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Proposal
Date: Mon, 09 Apr 2007 12:24:53 +0000 [thread overview]
Message-ID: <20070409142453.880b9785.khali@linux-fr.org> (raw)
In-Reply-To: <200704081630.17151.hjk@linutronix.de>
Hi Hans,
On Sun, 08 Apr 2007 15:51:02 +0200, Hans de Goede wrote:
> The abituguru3 driver, of which I've just submitted a second version for
> review, has a new feature / sysfs file, which I would like to discuss, before
> people think I'm trying to keep this new sysfs entry below the radar.
>
> The abituguru3 has a register which contains a motherboard ID. The current
> driver uses this ID, to look up info about the motherboard in a somewhat lenght
> table in the driver. This is done this way because the uguru3 has 48 sensors,
> and the only way to know which one are actually connected and wether they are
> connected to voltage / temp / fan is by using this table. The added advantage
> of this is that since we know exactly on which motherboard the driver is
> running, additional stuff can be don. Like always correct values in mV / milli
> degress celcius / RPM at the sysfs level without libsensors needing todo any
As I already expressed further in the thread: this violates the design
decision all other hardware monitoring drivers are built upon.
Conversions, and motherboard support in general, belong to user-space.
> conversion. An other additional feature this enables, is telling userspace
> which voltage / temp / fan is actually being monitored. So the abituguru3
> driver has sysfs entries like:
> /sys/class/hwmon/hwmon0/in0_label
>
> Catting this file will result (depependend on motherboard) in for example:
> CPU Core
> being returned
>
> I personally like this, as with proper userspace support this makes the end
> user experience pretty plug and play. so what do you think, good or bad?
>
> Currently libsensors cannot handle this, but I don't think that is an argument
> either way.
I am, however, fine with *_label entries in sysfs, as long as they are
used with care. The use of these entries should be limited to the case
where pin use can be probed by the driver from the hardware state.
BTW, the coretemp driver already creates these files, even though it is
not properly documented in Documentation/hwmon/sysfs-interface yet. And
I have plans to create some label files in the it87 driver too.
These sysfs files should not be seen as a replacement for sensors.conf's
label statements. They should only be created when the driver knows,
directly from the hardware, that a given input is used for a
well-defined function, and user-space couldn't know that.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2007-04-09 12:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-08 14:30 [lm-sensors] Proposal Hans-Jürgen Koch
2007-04-08 17:36 ` Hans de Goede
2007-04-08 18:31 ` Hans-Jürgen Koch
2007-04-08 18:56 ` Hans de Goede
2007-04-08 19:18 ` Hans-Jürgen Koch
2007-04-09 11:23 ` Jean Delvare
2007-04-09 11:27 ` Jean Delvare
2007-04-09 12:24 ` Jean Delvare [this message]
2007-04-09 12:26 ` Hans de Goede
2007-04-09 12:34 ` Hans de Goede
2007-04-09 12:50 ` Hans de Goede
2007-04-11 11:35 ` Jean Delvare
2007-04-11 11:49 ` Jean Delvare
2007-04-11 11:56 ` Jean Delvare
2007-04-11 13:49 ` Hans de Goede
2007-06-16 15:14 ` Mark M. Hoffman
2007-06-16 15:21 ` Mark M. Hoffman
2007-06-16 15:42 ` Mark M. Hoffman
2007-06-16 19:35 ` Hans de Goede
2007-06-16 19:40 ` Hans de Goede
2007-06-16 19:50 ` Hans de Goede
2007-06-16 19:52 ` Mark M. Hoffman
2007-06-18 18:31 ` Jean Delvare
2007-06-18 19:58 ` Hans de Goede
2007-06-19 7:59 ` Jean Delvare
2007-06-19 8:15 ` Jean Delvare
2007-06-19 8:31 ` Hans de Goede
2007-06-19 12:27 ` Mark M. Hoffman
2007-06-24 11:43 ` Jean Delvare
2007-06-24 12:11 ` 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=20070409142453.880b9785.khali@linux-fr.org \
--to=khali@linux-fr.org \
--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.