Партнёры:
Хостинг:
sensors.conf - libsensors configuration file
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:
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.
This section describes the meaning of each statement. Each statement is accompanied by an example line. Please ignore line wrap-arounds.
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 i2c-, followed by a number. As there is a dash in this argument, it must always be quoted.
The second and third arguments are the description texts. They must be exactly match the texts as they appear in /proc/bus/i2c, except for trailing spaces, which are removed both from the /proc entries and the arguments. The adapter description comes first, followed by the algorithm description.
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.
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 chip descriptions are equal to those appearing in /proc/sys/dev/sensors, but may contain the * wildcard.
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 isa or 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 non-ISA bus').
The third element is the hexadecimal address. This is a number between 0 and ffff for the ISA bus, and between 0 and 7f for an I2C bus. 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-10-5e or lm78-isa-10dd:
lm78-i2c-10-*
lm78-i2c-*-5e
lm78-i2c-*-*
lm78-isa-10dd
lm78-isa-*
lm78-*
*-i2c-10-5e
*-i2c-10-*
*-i2c-*-5e
*-i2c-*-*
*-isa-10dd
*-isa-*
*-*
*
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.
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).
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.
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.
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 explicitely.
A simple example will explain this better. The fan1 label class of the lm78 chip contains three members: fan1 itself, fan1_min and 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:
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.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |