redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity

hwmon: Update the sysfs interface documentation

Browse source 
* Document the characteristics of libsensors 3.0.0 and 3.0.1.
* The sysfs interface is no longer subject to changes.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Juerg Haefliger <juergh at gmail.com>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
This commit is contained in:
Jean Delvare 2008-02-23 10:57:53 +01:00 committed by Mark M. Hoffman
parent ed4ec814e4
commit 125ff8087f
1 changed files with 13 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
Documentation/hwmon/sysfs-interface
View file

@ -2,17 +2,12 @@ Naming and data format standards for sysfs files
------------------------------------------------ ------------------------------------------------
The libsensors library offers an interface to the raw sensors data The libsensors library offers an interface to the raw sensors data
through the sysfs interface. See libsensors documentation and source for through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
further information. As of writing this document, libsensors completely chip-independent. It assumes that all the kernel drivers
(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating implement the standard sysfs interface described in this document.
support for any given chip requires modifying the library's code. This makes adding or updating support for any given chip very easy, as
This is because libsensors was written for the procfs interface libsensors, and applications using it, do not need to be modified.
older kernel modules were using, which wasn't standardized enough. This is a major improvement compared to lm-sensors 2.
Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
support for the sysfs interface, though.
The new sysfs interface was designed to be as chip-independent as
possible.
Note that motherboards vary widely in the connections to sensor chips. Note that motherboards vary widely in the connections to sensor chips.
There is no standard that ensures, for example, that the second There is no standard that ensures, for example, that the second
@ -35,19 +30,17 @@ access this data in a simple and consistent way. That said, such programs
will have to implement conversion, labeling and hiding of inputs. For will have to implement conversion, labeling and hiding of inputs. For
this reason, it is still not recommended to bypass the library. this reason, it is still not recommended to bypass the library.
If you are developing a userspace application please send us feedback on
this standard.
Note that this standard isn't completely established yet, so it is subject
to changes. If you are writing a new hardware monitoring driver those
features can't seem to fit in this interface, please contact us with your
extension proposal. Keep in mind that backward compatibility must be
preserved.
Each chip gets its own directory in the sysfs /sys/devices tree. To Each chip gets its own directory in the sysfs /sys/devices tree. To
find all sensor chips, it is easier to follow the device symlinks from find all sensor chips, it is easier to follow the device symlinks from
/sys/class/hwmon/hwmon*. /sys/class/hwmon/hwmon*.
Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
in the hwmon "class" device directory are also supported. Complex drivers
(e.g. drivers for multifunction chips) may want to use this possibility to
avoid namespace pollution. The only drawback will be that older versions of
libsensors won't support the driver in question.
All sysfs values are fixed point numbers. All sysfs values are fixed point numbers.
There is only one value per file, unlike the older /proc specification. There is only one value per file, unlike the older /proc specification.