Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
The ONE Campaign to make poverty history

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 179 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

sensors.conf




DESCRIPTION

       sensors.conf describes how libsensors, and so all programs
       using it, should translate the raw readings from the  ker­
       nel 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 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:

              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
       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 dis­
       tribution can help you generate these lines.

   CHIP STATEMENT
              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
       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 sev­
       eral 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').

              lm78-i2c-*-*
              lm78-isa-10dd
              lm78-isa-*
              lm78-*
              *-i2c-10-5e
              *-i2c-10-*
              *-i2c-*-5e
              *-i2c-*-*
              *-isa-10dd
              *-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  trans­
       lated  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  expres­
       sions; you should be careful though to avoid circular ref­
       erences, 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  state­
       ment 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 val­
       ues  (for  example, because a fan or temperature sensor is
       not connected).

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

   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 argu­
       ment 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 expres­
       sions; 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 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  follow­
       ing  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! Fortu­
       nately, the fan1 compute class contains fan1_min, but  not
       fan1_div, so this works out right.


CONFORMING TO

       lm_sensors-2.x


SEE ALSO

       sensors.conf(5)

                         February 8, 1999         sensors.conf(5)
  




Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can choose larger fonts by selecting a different themes.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.04 Seconds