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

Revision 4787, 10.7 KB (checked in by khali, 7 years ago)

The sensors.conf man page belongs to the user's manual, not the
programmer's manual.

  • 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  "April 2007" "" "Linux User'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 must 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\-*" "lm79\-*"
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!).
195
196The first element is the name of the chip type. Sometimes a single driver
197implements several chip types, with several names. The driver documentation
198should tell you. You may substitute the wildcard operator
199.I *
200for this element.
201
202The second element is the name of the bus. This is either
203.IR isa ,
204.I pci
205or
206.IR i2c-N ,
207with
208.I N
209being any number as binded with a
210.I bus
211statement. You may substitute the wildcard operator
212.I *
213for this element, or only for the number of the I2C bus
214(which means 'any I2C bus').
215
216The third element is the hexadecimal address of the chip. The valid range
217depends on the bus type. You may substitute
218the wildcard operator
219.I *
220for this element.
221
222There are some folding rules for wildcards to make things easier for humans
223to read. Also, you can't specify the address if you wildcard the complete
224second element. The following are all valid chip type specification based
225on
226.I lm78\-i2c\-1\-2d
227or
228.IR lm78\-isa\-0290 :
229
230.RS
231lm78\-i2c\-1\-2d
232.sp 0
233lm78\-i2c\-1\-*
234.sp 0
235lm78\-i2c\-*\-2d
236.sp 0
237lm78\-i2c\-*\-*
238.sp 0
239lm78\-isa\-0290
240.sp 0
241lm78\-isa\-*   
242.sp 0
243lm78\-*       
244.sp 0
245*\-i2c\-1\-2d
246.sp 0
247*\-i2c\-1\-*
248.sp 0
249*\-i2c\-*\-2d
250.sp 0
251*\-i2c-*\-*
252.sp 0
253*\-isa\-0290
254.sp 0
255*\-isa\-*
256.sp 0
257*\-*
258.sp 0
259*
260.RE
261
262.SS COMPUTE STATEMENT
263.RS
264compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
265.RE
266
267The
268.I compute
269statement describes how you should translate a feature's raw value to a
270real\-world value, and how you should translate it back to a raw value again.
271
272The first argument is the feature name, which may be the name of a feature
273class (see below). The second is an expression which specifies how a
274raw value must be translated to a real\-world value; `@' stands here for
275the raw value. The third is an expression that specifies how a real\-world
276value should be translated back to a raw value; `@' stands here for the
277real\-world value.
278
279You may use the name of other features in these expressions; you should be
280careful though to avoid circular references, as this may hang the expression
281evaluator.
282
283If at any moment a translation between a raw and a real\-world value is
284called for, but no
285.I compute
286statement applies, a one\-on\-one translation is used instead.
287
288The comma is an unfortunate necessity to stop the statement from becoming
289ambiguous.
290
291.SS IGNORE STATEMENT
292.RS
293ignore fan1
294.RE
295
296The
297.I ignore
298statement is a hint that a specific feature should be ignored - probably
299because it returns bogus values (for example, because a fan or temperature
300sensor is not connected).
301
302The only argument is the feature name, which may be a feature class;
303in that case the label class is used (see below).
304
305.SS LABEL STATEMENT
306.RS
307label in3 "+5V"
308.RE
309
310The
311.I label
312statement describes how a feature should be called. Features without a
313.I label
314statement are just called by their feature name. Applications can use this
315to label the readings they present (but they don't have to).
316
317The first argument is the feature name, which may be a feature class (see
318below). The second argument is the feature description.
319
320.SS SET STATEMENT
321.RS
322set in3_min  5 * 0.95
323.RE
324
325The
326.I set
327statement gives an initial value for a feature. Not each feature can be
328given a sensible initial value; valid features are usually min/max limits.
329
330The first argument is the feature name. The second argument is an expression
331which determines the initial value. If there is an applying
332.I compute
333statement, this value is fed to its third argument to translate it to a
334raw value.
335
336You may use the name of other features in these expressions; current readings
337are substituted. You should be careful though to avoid circular references,
338as this may hang the expression evaluator. Also, you can't be sure in which
339order
340.I set
341statements are evaluated, so this can lead to nasty surprises.
342
343.SH FEATURE CLASSES
344
345There are two kinds of classes, here called
346.I compute
347and
348.I label
349classes, after the statements for which they are defined. Classes are
350defined over features: the kind of values that can be read from or set
351for a specific kind of chip.
352
353Each class has a class name, which is usually the same as its most
354prominent feature. A
355.I label
356or
357.I compute
358statement for the class name feature forces the same settings for all other
359class members. A specific statement for a class member feature always
360overrides the general class setting, though. This means that you can't
361override the class name feature explicitly.
362
363A simple example will explain this better. The
364.I fan1
365label class of the
366.I lm78
367chip contains three members:
368.I fan1
369itself,
370.I fan1_min
371and
372.IR fan1_div .
373The last feature sets the number by which readings are divided (to give the
374fan less resolution, but a larger field of operation). The following
375line will set the name of all these features to describe the fan:
376.RS
377label fan1 "Processor 1 FAN"
378.RE
379Now we happen to know that, due to the type of fan we use, all readings
380are always off by a factor of two (some fans only return one 'tick' each
381rotation, others return two):
382.RS
383compute fan1 @/2 , @*2
384.RE
385It will be clear that this should be done for the
386.I fan1_min
387feature too, but not for the
388.I fan1_div
389feature! Fortunately, the
390.I fan1
391compute class contains
392.IR fan1_min ,
393but not
394.IR fan1_div ,
395so this works out right.
396
397.SH WHICH STATEMENT APPLIES
398
399If more than one statement of the same kind applies at a certain moment,
400the last one in the configuration file is used. So usually, you should
401put more genereal
402.I chip
403statements at the top, so you can overrule them below.
404
405There is one exception to this rule: if a statement only applies because
406the feature is in the same class as the feature the statement contains,
407and there is anywhere else a statement for this specific class member,
408that one takes always precedence.
409
410.SH "CONFORMING TO"
411lm_sensors-2.x
412.SH SEE ALSO
413libsensors(3)
414
415.SH AUTHOR
416Frodo Looijaard and the lm_sensors group
417http://www.lm-sensors.org/
418
419
420
Note: See TracBrowser for help on using the browser.