root/lm-sensors/trunk/lib/sensors.conf.5 @ 4208

Revision 4208, 10.9 KB (checked in by khali, 8 years ago)

libsensors: Drop support for algorithm names.
I2C algorithms no longer have names in Linux 2.6, and anyway they are
implementation details user-space doesn't care about. No third party
application is known to have ever used this particular feature of
libsensors. "sensord" and "sensors" no longer do.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
Line 
1.\" Copyright 1998, 1999 Adrian Baugh <adrian.baugh@keble.ox.ac.uk> and
2.\" Frodo Looijaard <frodol@dds.nl>
3.\"
4.\" Permission is granted to make and distribute verbatim copies of this
5.\" manual provided the copyright notice and this permission notice are
6.\" preserved on all copies.
7.\"
8.\" Permission is granted to copy and distribute modified versions of this
9.\" manual under the conditions for verbatim copying, provided that the
10.\" entire resulting derived work is distributed under the terms of a
11.\" permission notice identical to this one
12.\"
13.\" Since the Linux kernel and libraries are constantly changing, this
14.\" manual page may be incorrect or out-of-date.  The author(s) assume no
15.\" responsibility for errors or omissions, or for damages resulting from
16.\" the use of the information contained herein.  The author(s) may not
17.\" have taken the same level of care in the production of this manual,
18.\" which is licensed free of charge, as they might when working
19.\" professionally.
20.\"
21.\" Formatted or processed versions of this manual, if unaccompanied by
22.\" the source, must acknowledge the copyright and authors of this work.
23.\"
24.\" References consulted:
25.\"     sensors.conf.eg by Frodo Looijaard
26.TH sensors.conf 5  "October 2006" "" "Linux Programmer's Manual"
27.SH NAME
28sensors.conf \- libsensors configuration file
29
30.SH DESCRIPTION
31sensors.conf describes how libsensors, and so all programs using it, should
32translate the raw readings from the kernel modules to real\-world values.
33
34.SH SYNTAX
35Comments are introduces by hash marks. A comment continues to the end of the
36line. Empty lines, and lines containing only whitespace or comments are
37ignored.  Other lines have one of the below forms. There should be whitespace
38between each element, but the amount of whitespace is unimportant. A line
39may be continued on the next line by ending it with a backslash; this does
40not work within a comment,
41.B NAME
42or
43.BR NUMBER .
44
45.RS
46bus
47.B NAME NAME NAME
48.sp 0
49chip
50.B NAME\-LIST
51.sp 0
52label
53.B NAME NAME
54.sp 0
55compute
56.B NAME EXPR
57,
58.B EXPR
59.sp 0
60ignore
61.B NAME
62.sp 0
63set
64.B NAME EXPR
65.RE
66.sp
67A
68.B NAME
69is a string. If it only contains letters, digits and underscores, it does not
70have to quoted; in all other cases, you should use double quotes around it.
71Within quotes, you can use the normal escape\-codes from C.
72
73A
74.B NAME\-LIST
75is one or more
76.B NAME
77items behind each other, separated by whitespace.
78
79A
80.B EXPR
81is of one of the below forms:
82
83.RS
84.B NUMBER
85.sp 0
86.B NAME
87.sp 0
88@
89.sp 0
90.B EXPR
91+
92.B EXPR
93.sp 0
94.B EXPR
95\-
96.B EXPR
97.sp 0
98.B EXPR
99*
100.B EXPR
101.sp 0
102.B EXPR
103/
104.B EXPR
105.sp 0
106\-
107.B EXPR
108.sp 0
109(
110.B EXPR
111)
112.RE
113
114A
115.B NUMBER
116is a floating\-point number. `10', `10.4' and `.4' are examples of valid
117floating\-point numbers; `10.' or `10E4' are not valid.
118
119.SH SEMANTICS
120
121This section describes the meaning of each statement. Each statement is
122accompanied by an example line. Please ignore line wrap\-arounds.
123
124.SS BUS STATEMENT
125
126.RS
127bus "i2c\-0" "SMBus PIIX4 adapter at e800"
128.RE
129
130A
131.I bus
132statement binds the description of an I2C or SMBus adapter to a bus number.
133This makes it possible to refer to an adapter in the configuration file,
134independent of the actual correspondence of bus numbers and actual
135adapters (which may change from moment to moment).
136
137The first argument is the bus number. It is the literal text
138.IR i2c\- ,
139followed by a number. As there is a dash in this argument, it must
140always be quoted.
141
142The second argument is the adapter name, it must match exactly the
143adapter name as it appears in
144.I /proc/bus/i2c
145(2.4 kernel)
146or
147.I /sys/class/i2c-adapter/i2c-*/device/name
148(2.6 kernel).
149It should always be quoted as well as it will most certainly contain
150spaces or dashes.
151
152There used to be a third argument, the algorithm name. For compatibility
153reasons, the parser still accepts this third argument, but ignores it.
154
155The
156.I bus
157statements may be scattered randomly throughout the configuration file;
158there is no need to place the bus line before the place where its binding
159is referred to. Still, as a matter of good style, we suggest you place
160all
161.I bus
162statements together at the top of your configuration file.
163
164The program
165.I prog/config/grab_busses.sh
166in the source distribution can help you generate these lines.
167
168.SS CHIP STATEMENT
169
170.RS
171chip "lm78\-*" "*\-isa\-*" "*\-i2c\-3"
172.RE
173
174The
175.I chip
176statement selects for which chips all following configuration
177statements are meant. The chip selection remains valid until the next
178.I chip
179statement. It does not influence the operation of a
180.I bus
181statement.
182
183If a chip matches at least one of the chip descriptions, all following
184configuration lines are examined for it. If it matches none of the
185chip descriptions, every
186.RI non\- bus
187statement is ignored upto the next
188.I chip
189statement.
190
191A chip description is built from a couple of elements, separated by
192dashes. To complicate matters, sometimes an element can also contain
193dashes. This complicates the parsing algorithm, but is not too confusing
194for humans (we hope!). The chip descriptions are equal to those
195appearing in
196.IR /proc/sys/dev/sensors ,
197but may contain the
198.I *
199wildcard.
200
201The first element is the name of the chip type. Sometimes a single driver
202implements several chip types, with several names. The driver documentation
203should tell you. You may substitute the wildcard operator
204.I *
205for this element.
206
207The second element is the name of the bus. This is either
208.I isa
209or
210.IR i2c-N ,
211with
212.I N
213being any number as binded with a
214.I bus
215statement. You may substitute the wildcard operator
216.I *
217for this element, or only for the number of the I2C bus
218(which means 'any non-ISA bus').
219
220The third element is the hexadecimal address. This is a number between 0 and
221ffff for the ISA bus, and between 0 and 7f for an I2C bus. You may substitute
222the wildcard operator
223.I *
224for this element.
225
226There are some folding rules for wildcards to make things easier for humans
227to read. Also, you can't specify the address if you wildcard the complete
228second element. The following are all valid chip type specification based
229on
230.I lm78\-i2c\-10\-5e
231or
232.IR lm78\-isa\-10dd :
233
234.RS
235lm78\-i2c\-10\-5e     
236.sp 0
237lm78\-i2c\-10\-*     
238.sp 0
239lm78\-i2c\-*\-5e   
240.sp 0
241lm78\-i2c\-*\-*   
242.sp 0
243lm78\-isa\-10dd 
244.sp 0
245lm78\-isa\-*   
246.sp 0
247lm78\-*       
248.sp 0
249*\-i2c\-10\-5e
250.sp 0
251*\-i2c\-10\-*
252.sp 0
253*\-i2c\-*\-5e
254.sp 0
255*\-i2c-*\-*
256.sp 0
257*\-isa\-10dd
258.sp 0
259*\-isa\-*
260.sp 0
261*\-*
262.sp 0
263*
264.RE
265
266.SS COMPUTE STATEMENT
267.RS
268compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
269.RE
270
271The
272.I compute
273statement describes how you should translate a feature's raw value to a
274real\-world value, and how you should translate it back to a raw value again.
275
276The first argument is the feature name, which may be the name of a feature
277class (see below). The second is an expression which specifies how a
278raw value must be translated to a real\-world value; `@' stands here for
279the raw value. The third is an expression that specifies how a real\-world
280value should be translated back to a raw value; `@' stands here for the
281real\-world value.
282
283You may use the name of other features in these expressions; you should be
284careful though to avoid circular references, as this may hang the expression
285evaluator.
286
287If at any moment a translation between a raw and a real\-world value is
288called for, but no
289.I compute
290statement applies, a one\-on\-one translation is used instead.
291
292The comma is an unfortunate necessity to stop the statement from becoming
293ambiguous.
294
295.SS IGNORE STATEMENT
296.RS
297ignore fan1
298.RE
299
300The
301.I ignore
302statement is a hint that a specific feature should be ignored - probably
303because it returns bogus values (for example, because a fan or temperature
304sensor is not connected).
305
306The only argument is the feature name, which may be a feature class;
307in that case the label class is used (see below).
308
309.SS LABEL STATEMENT
310.RS
311label in3 "+5V"
312.RE
313
314The
315.I label
316statement describes how a feature should be called. Features without a
317.I label
318statement are just called by their feature name. Applications can use this
319to label the readings they present (but they don't have to).
320
321The first argument is the feature name, which may be a feature class (see
322below). The second argument is the feature description.
323
324.SS SET STATEMENT
325.RS
326set in3_min  5 * 0.95
327.RE
328
329The
330.I set
331statement gives an initial value for a feature. Not each feature can be
332given a sensible initial value; valid features are usually min/max limits.
333
334The first argument is the feature name. The second argument is an expression
335which determines the initial value. If there is an applying
336.I compute
337statement, this value is fed to its third argument to translate it to a
338raw value.
339
340You may use the name of other features in these expressions; current readings
341are substituted. You should be careful though to avoid circular references,
342as this may hang the expression evaluator. Also, you can't be sure in which
343order
344.I set
345statements are evaluated, so this can lead to nasty surprises.
346
347.SH FEATURE CLASSES
348
349There are two kinds of classes, here called
350.I compute
351and
352.I label
353classes, after the statements for which they are defined. Classes are
354defined over features: the kind of values that can be read from or set
355for a specific kind of chip.
356
357Each class has a class name, which is usually the same as its most
358prominent feature. A
359.I label
360or
361.I compute
362statement for the class name feature forces the same settings for all other
363class members. A specific statement for a class member feature always
364overrides the general class setting, though. This means that you can't
365override the class name feature explicitly.
366
367A simple example will explain this better. The
368.I fan1
369label class of the
370.I lm78
371chip contains three members:
372.I fan1
373itself,
374.I fan1_min
375and
376.IR fan1_div .
377The last feature sets the number by which readings are divided (to give the
378fan less resolution, but a larger field of operation). The following
379line will set the name of all these features to describe the fan:
380.RS
381label fan1 "Processor 1 FAN"
382.RE
383Now we happen to know that, due to the type of fan we use, all readings
384are always off by a factor of two (some fans only return one 'tick' each
385rotation, others return two):
386.RS
387compute fan1 @/2 , @*2
388.RE
389It will be clear that this should be done for the
390.I fan1_min
391feature too, but not for the
392.I fan1_div
393feature! Fortunately, the
394.I fan1
395compute class contains
396.IR fan1_min ,
397but not
398.IR fan1_div ,
399so this works out right.
400
401.SH WHICH STATEMENT APPLIES
402
403If more than one statement of the same kind applies at a certain moment,
404the last one in the configuration file is used. So usually, you should
405put more genereal
406.I chip
407statements at the top, so you can overrule them below.
408
409There is one exception to this rule: if a statement only applies because
410the feature is in the same class as the feature the statement contains,
411and there is anywhere else a statement for this specific class member,
412that one takes always precedence.
413
414.SH "CONFORMING TO"
415lm_sensors-2.x
416.SH SEE ALSO
417libsensors(3)
418
419.SH AUTHOR
420Frodo Looijaard and the lm_sensors group
421http://www.lm-sensors.org/
422
423
424
Note: See TracBrowser for help on using the browser.