[lm-sensors] Proposal /sys/bus/class/hwmon/hwmon#/device/foo#_label
Hans de Goede
j.w.r.degoede at hhs.nl
Mon Apr 9 14:34:35 CEST 2007
Jean Delvare wrote:
> Hi Hans,
> On Sun, 08 Apr 2007 19:36:47 +0200, Hans de Goede wrote:
>> Hans-Jürgen Koch wrote:
>>> Am Sonntag 08 April 2007 15:51 schrieb Hans de Goede:
>>>> 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.
>>> Can you elaborate your design decision a bit? My first idea would be to have
>>> a sysfs file that delivers that motherboard ID and then do the lookup in
>>> user space.
> I guess that the motherboard ID can be retrieved in user-space using
> dmidecode, can't it? So it might not even be needed to export it.
>> As I don't want the abituguru3 driver to create entries in sysfs for sensors
>> which aren't there, and as without the table in the driver I cannot be sure
>> wether to create an in / temp / fan device for a given sensor address. Last but
>> not least doing things this way allows me to always give a proper reading
>> without userspace needing to "guess" any further nescesarry calculations to get
>> from the reading to an actual measurement.
> This is absolutely not different from all other hardware monitoring
> drivers. And all other drivers handle it in user-space, because that's
> the right design. I see no valid reason why it would be different for
> your abituguru3 driver. All you need is one configuration file per
Oh and another thing I just came up with, last time I checked, it isn't
possible from userspace to change an inX_input to a tempX_input, or are you
suggesting that I export all 48 sensors, 3 times, once as in, once as temp and
once as fan and them make user space ignore temp1 and fan1, and use in0, as
sensor 0/1 actually is an in sensor?
More information about the lm-sensors