Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for sensors.conf (redhat section 5)

sensors.conf(5) 		    Linux Programmer's Manual			  sensors.conf(5)

       sensors.conf - libsensors configuration file

       sensors.conf  describes how libsensors, and so all programs using it, should translate the
       raw readings from the kernel modules to real-world values.

       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 should 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 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:

	      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  float-
       ing-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.

	      bus "i2c-0" "SMBus PIIX4 adapter at e800" "Non-I2C SMBus adapter"

       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

       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.

	      chip "lm78-*" "*-isa-*" "*-i2c-3"

       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  influ-
       ence 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  algo-
       rithm,  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  sev-
       eral  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:


	      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 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

       The  only  argument  is	the  feature name, which may be a feature class; in that case the
       label class is used (see below).

	      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 sec-
       ond argument is the feature description.

	      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  deter-
       mines  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  substi-
       tuted.  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 state-
       ments 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

       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 opera-
       tion). 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 fan1_min, but not fan1_div,
       so this works out right.

       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  state-
       ment for this specific class member, that one takes always precedence.



					 February 8, 1999			  sensors.conf(5)

All times are GMT -4. The time now is 08:53 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password