From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Proposal /sys/bus/class/hwmon/hwmon#/device/foo#_label
Date: Sun, 08 Apr 2007 13:51:02 +0000 [thread overview]
Message-ID: <4618F346.3000404@hhs.nl> (raw)
Hi all,
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
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.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
reply other threads:[~2007-04-08 13:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4618F346.3000404@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.