sensors.conf
NAME
sensors.conf - libsensors configuration file
DESCRIPTION
sensors.conf describes how libsensors, and so all programs using it, should
translate the raw readings from the kernel modules to real-world values.
SYNTAX
Comments are introduces by hash marks. A comment continues to the end of the
line. Empty lines, and lines containing only whitespace or comments are
ignored. Other lines have one of the below forms. There must be whitespace
between each element, but the amount of whitespace is unimportant. A line
may be continued on the next line by ending it with a backslash; this does
not work within a comment,
NAME
or
R NUMBER .
bus
NAME NAME NAME
chip
NAME-LIST
label
NAME NAME
compute
NAME EXPR
,
EXPR
ignore
NAME
set
NAME EXPR
A
NAME
is a string. If it only contains letters, digits and underscores, it does not
have to quoted; in all other cases, you should use double quotes around it.
Within quotes, you can use the normal escape-codes from C.
A
NAME-LIST
is one or more
NAME
items behind each other, separated by whitespace.
A
EXPR
is of one of the below forms:
NUMBER
NAME
@
EXPR
+
EXPR
EXPR
-
EXPR
EXPR
*
EXPR
EXPR
/
EXPR
-
EXPR
(
EXPR
)
A
NUMBER
is a floating-point number. `10', `10.4' and `.4' are examples of valid
floating-point numbers; `10.' or `10E4' are not valid.
SEMANTICS
This section describes the meaning of each statement. Each statement is
accompanied by an example line. Please ignore line wrap-arounds.
BUS STATEMENT
bus "i2c-0" "SMBus PIIX4 adapter at e800"
A
bus
statement binds the description of an I2C or SMBus adapter to a bus number.
This makes it possible to refer to an adapter in the configuration file,
independent of the actual correspondence of bus numbers and actual
adapters (which may change from moment to moment).
The first argument is the bus number. It is the literal text
R i2c- ,
followed by a number. As there is a dash in this argument, it must
always be quoted.
The second argument is the adapter name, it must match exactly the
adapter name as it appears in
/proc/bus/i2c
(2.4 kernel)
or
/sys/class/i2c-adapter/i2c-*/device/name
(2.6 kernel).
It should always be quoted as well as it will most certainly contain
spaces or dashes.
There used to be a third argument, the algorithm name. For compatibility
reasons, the parser still accepts this third argument, but ignores it.
The
bus
statements may be scattered randomly throughout the configuration file;
there is no need to place the bus line before the place where its binding
is referred to. Still, as a matter of good style, we suggest you place
all
bus
statements together at the top of your configuration file.
The program
prog/config/grab_busses.sh
in the source distribution can help you generate these lines.
CHIP STATEMENT
chip "lm78-*" "lm79-*"
The
chip
statement selects for which chips all following configuration
statements are meant. The chip selection remains valid until the next
chip
statement. It does not influence the operation of a
bus
statement.
If a chip matches at least one of the chip descriptions, all following
configuration lines are examined for it. If it matches none of the
chip descriptions, every
non-bus
statement is ignored upto the next
chip
statement.
A chip description is built from a couple of elements, separated by
dashes. To complicate matters, sometimes an element can also contain
dashes. This complicates the parsing algorithm, but is not too confusing
for humans (we hope!).
The first element is the name of the chip type. Sometimes a single driver
implements several chip types, with several names. The driver documentation
should tell you. You may substitute the wildcard operator
*
for this element.
The second element is the name of the bus. This is either
R isa ,
pci
or
R i2c-N ,
with
N
being any number as binded with a
bus
statement. You may substitute the wildcard operator
*
for this element, or only for the number of the I2C bus
(which means 'any I2C bus').
The third element is the hexadecimal address of the chip. The valid range
depends on the bus type. You may substitute
the wildcard operator
*
for this element.
There are some folding rules for wildcards to make things easier for humans
to read. Also, you can't specify the address if you wildcard the complete
second element. The following are all valid chip type specification based
on
lm78-i2c-1-2d
or
R lm78-isa-0290 :
lm78-i2c-1-2d
lm78-i2c-1-*
lm78-i2c-*-2d
lm78-i2c-*-*
lm78-isa-0290
lm78-isa-*
lm78-*
*-i2c-1-2d
*-i2c-1-*
*-i2c-*-2d
*-i2c-*-*
*-isa-0290
*-isa-*
*-*
*
COMPUTE STATEMENT
compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)
The
compute
statement describes how you should translate a feature's raw value to a
real-world value, and how you should translate it back to a raw value again.
The first argument is the feature name, which may be the name of a feature
class (see below). The second is an expression which specifies how a
raw value must be translated to a real-world value; `@' stands here for
the raw value. The third is an expression that specifies how a real-world
value should be translated back to a raw value; `@' stands here for the
real-world value.
You may use the name of other features in these expressions; you should be
careful though to avoid circular references, as this may hang the expression
evaluator.
If at any moment a translation between a raw and a real-world value is
called for, but no
compute
statement applies, a one-on-one translation is used instead.
The comma is an unfortunate necessity to stop the statement from becoming
ambiguous.
IGNORE STATEMENT
ignore fan1
The
ignore
statement is a hint that a specific feature should be ignored - probably
because it returns bogus values (for example, because a fan or temperature
sensor is not connected).
The only argument is the feature name, which may be a feature class;
in that case the label class is used (see below).
LABEL STATEMENT
label in3 "+5V"
The
label
statement describes how a feature should be called. Features without a
label
statement are just called by their feature name. Applications can use this
to label the readings they present (but they don't have to).
The first argument is the feature name, which may be a feature class (see
below). The second argument is the feature description.
SET STATEMENT
set in3_min 5 * 0.95
The
set
statement gives an initial value for a feature. Not each feature can be
given a sensible initial value; valid features are usually min/max limits.
The first argument is the feature name. The second argument is an expression
which determines the initial value. If there is an applying
compute
statement, this value is fed to its third argument to translate it to a
raw value.
You may use the name of other features in these expressions; current readings
are substituted. You should be careful though to avoid circular references,
as this may hang the expression evaluator. Also, you can't be sure in which
order
set
statements are evaluated, so this can lead to nasty surprises.
FEATURE CLASSES
There are two kinds of classes, here called
compute
and
label
classes, after the statements for which they are defined. Classes are
defined over features: the kind of values that can be read from or set
for a specific kind of chip.
Each class has a class name, which is usually the same as its most
prominent feature. A
label
or
compute
statement for the class name feature forces the same settings for all other
class members. A specific statement for a class member feature always
overrides the general class setting, though. This means that you can't
override the class name feature explicitly.
A simple example will explain this better. The
fan1
label class of the
lm78
chip contains three members:
fan1
itself,
fan1_min
and
R fan1_div .
The last feature sets the number by which readings are divided (to give the
fan less resolution, but a larger field of operation). The following
line will set the name of all these features to describe the fan:
label fan1 "Processor 1 FAN"
Now we happen to know that, due to the type of fan we use, all readings
are always off by a factor of two (some fans only return one 'tick' each
rotation, others return two):
compute fan1 @/2 , @*2
It will be clear that this should be done for the
fan1_min
feature too, but not for the
fan1_div
feature! Fortunately, the
fan1
compute class contains
R fan1_min ,
but not
R fan1_div ,
so this works out right.
WHICH STATEMENT APPLIES
If more than one statement of the same kind applies at a certain moment,
the last one in the configuration file is used. So usually, you should
put more genereal
chip
statements at the top, so you can overrule them below.
There is one exception to this rule: if a statement only applies because
the feature is in the same class as the feature the statement contains,
and there is anywhere else a statement for this specific class member,
that one takes always precedence.
CONFORMING TO
lm_sensors-2.x
SEE ALSO
libsensors(3)
AUTHOR
Frodo Looijaard and the lm_sensors group
http://www.lm-sensors.org/
ČLÁNKY DO MAILU