/[gentoo]/xml/htdocs/doc/en/devfs-guide.xml
Gentoo

Contents of /xml/htdocs/doc/en/devfs-guide.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (show annotations) (download) (as text)
Sat Nov 15 00:35:18 2003 UTC (10 years, 9 months ago) by neysx
Branch: MAIN
Changes since 1.2: +1 -0 lines
File MIME type: application/xml
Added $Header$ cvs tag -- NO CONTENT CHANGE

1 <?xml version='1.0' encoding="UTF-8"?>
2 <!-- $Header$ -->
3
4 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
5
6 <guide link="/doc/en/devfs-guide.xml">
7 <title>Device File System Guide</title>
8 <author title="Author">
9 <mail link="swift@gentoo.org">Sven Vermeulen</mail>
10 </author>
11 <author title="Reviewer">
12 <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
13 </author>
14
15 <abstract>
16 In this document you'll find information on what devfs is really about
17 and how to work with it.
18 </abstract>
19 <version>0.1</version>
20 <date>September 11, 2003</date>
21 <license/>
22 <chapter>
23 <title>What is devfs?</title>
24
25 <section>
26 <title>The (good?) old days</title>
27 <body>
28
29 <p>
30 Traditional Linux implementations provide their users with an
31 abstract device path, called <path>/dev</path>. Inside this path the
32 user finds <e>device nodes</e>, special files that represent devices
33 inside their system. For instance, <path>/dev/hda</path> represents the
34 first IDE device in their system. By providing device files to the
35 users, they can create programs that interact with hardware as if the
36 hardware was a regular file instead of using special APIs.
37 </p>
38
39 <p>
40 The device files are split in two groups, called <e>character</e>
41 devices and <e>block</e> devices. The first group consists of hardware
42 of which read/writes are not buffered. The second group naturally
43 consists of hardware of which read/writes are buffered. Both devices can
44 be read one character at a time, or in blocks. Therefore, the naming
45 might sound confusing and in fact is wrong.
46 </p>
47
48 <p>
49 If you take a look at a certain device file, you might find something
50 like this:
51 </p>
52
53 <pre caption = "Checking the information of a device file">
54 # <i>ls -l /dev/hda</i>
55 brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda
56 </pre>
57
58 <p>
59 In the previous example we see that <path>/dev/hda</path> is a block
60 device. However, more importantly, it has two special numbers assigned
61 to it: <path>3, 0</path>. This pair is called the <e>major-minor</e>
62 pair. It is used by the kernel to map a device file to a real device.
63 The major corresponds with a certain device, the minor with a subdevice.
64 Seems confusing? It isn't.
65 </p>
66
67 <p>
68 Two examples are <path>/dev/hda4</path> and <path>/dev/tty5</path>. The
69 first device file corresponds with the fourth partition on the first IDE
70 device. Its major-minor pair is <path>3, 4</path>. In other words, the
71 minor corresponds with the partition where the major corresponds with
72 the device. The second example has <path>4, 5</path> as major-minor
73 pair. In this case, the major corresponds with the terminal driver,
74 while the minor corresponds with the terminal number (in this case, the
75 fifth terminal).
76 </p>
77
78 </body>
79 </section>
80
81 <section>
82 <title>The problems</title>
83 <body>
84
85 <p>
86 If you do a quick check in such a <path>/dev</path>, you'll find out
87 that not only all your devices are listed, but <e>all</e> possible
88 devices that you can imagine. In other words, you have device files for
89 devices you don't have. Managing such a device group is cumbersome to
90 say the least. Imagine having to change the permissions of all device
91 files that have a corresponding device in your system, and leaving the
92 rest of the device files as they are.
93 </p>
94
95 <p>
96 When you add new hardware to your system, and this hardware didn't have
97 a device file previously, you would have to create one. Advanced users know
98 that this task can be accomplished with <c>./MAKEDEV</c> inside the
99 <path>/dev</path> tree, but do you immediately know what device you have
100 to create?
101 </p>
102
103 <p>
104 When you have programs interacting with hardware using the device files,
105 you can't have the root partition mounted read only, while there is no
106 further need to have it mounted read-write. And you can't have
107 <path>/dev</path> on a seperate partition, since <c>mount</c> needs
108 <path>/dev</path> to mount partitions.
109 </p>
110
111 </body>
112 </section>
113 <section>
114 <title>The solutions</title>
115 <body>
116
117 <p>
118 As you can imagine, the kernel hackers have found quite a number of
119 solutions to the aforementioned problems. However, many of them had
120 other flaws as described in
121 <uri>http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why</uri>.
122 We are not going to talk about these implementations, but focus on the
123 one implementation that did make it to the official kernel sources:
124 devfs.
125 </p>
126
127 </body>
128 </section>
129 <section>
130 <title>devfs as all-round winner</title>
131 <body>
132
133 <p>
134 devfs tackles all listed problems. It only provides the user with
135 existing devices, adds new nodes when new devices are found, and makes
136 it possible to mount the root filesystem read only. And it tackles more
137 problems we haven't discussed previously because they are less
138 interesting for users...
139 </p>
140
141 <p>
142 For instance, with devfs, you don't have to worry about major/minor
143 pairs. It is still supported (for backwards compatibility), but isn't
144 needed. This makes it possible for Linux to support even more devices,
145 since there are no limits anymore (numbers always have boundaries :)
146 </p>
147
148 </body>
149 </section>
150
151 </chapter>
152 <chapter>
153 <title>Navigating through the device tree</title>
154
155 <section>
156 <title>Directories</title>
157 <body>
158
159 <p>
160 One of the first things you might notice is that devfs uses directories
161 to group devices together. This improves readability, as now all related
162 devices are inside a common directory.
163 </p>
164
165 <p>
166 For instance, all IDE-related devices are inside the
167 <path>/dev/ide/</path> device directory, and SCSI-related devices are inside
168 <path>/dev/scsi/</path>. SCSI and IDE disks are seen in the same way,
169 meaning they both have the same subdirectory structure.
170 </p>
171
172 <p>
173 IDE and SCSI disks are controlled by an adapter (on-board or a seperate
174 card), called the <e>host</e>. Every adapter can have several channels.
175 A channel is called a <e>bus</e>. On each channel, you can have several
176 IDs. Such an ID identifies a disk. This ID is called the <e>target</e>.
177 Some SCSI devices can have multiple luns (<e>Logical Unit Numbers</e>),
178 for instance devices that handle multiple media simultaneously (hi-end
179 tapedrives). You mostly have only a single lun, <path>lun0/</path>.
180 </p>
181
182 <p>
183 So, whereas <path>/dev/hda4</path> was used previously, we now have
184 <path>/dev/ide/host0/bus0/target0/lun0/part4</path>. This is far more
185 easy... no, don't argue with me... it <e>is</e> easier... ah whatever!
186 :)
187 </p>
188
189 <note>
190 You can also use more Unix-like device file naming for hard disks, such as
191 <path>c0b0t0u0p2</path>. They can be found in <path>/dev/ide/hd</path>,
192 <path>/dev/scsi/hd</path> etc.
193 </note>
194
195 <p>
196 To give you an idea on the directories, this is a listing of the
197 directories which I have on my laptop:
198 </p>
199
200 <pre caption = "Directories in /dev">
201 cdroms/ cpu/ discs/ floppy/
202 ide/ input/ loop/ misc/
203 netlink/ printers/ pts/ pty/
204 scsi/ sg/ shm/ sound/
205 sr/ usb/ vc/ vcc/
206 </pre>
207
208 </body>
209 </section>
210 <section>
211 <title>Backwards compatibility using devfsd</title>
212 <body>
213
214 <p>
215 Using this new scheme sounds fun, but several tools and programs make
216 use of the previous, old scheme. To make sure no system is broken,
217 <c>devfsd</c> is created. This daemon creates symlinks with the old
218 names, pointing to the new device files.
219 </p>
220
221 <pre caption = "Created symlinks">
222 $ <i>ls -l /dev/hda4</i>
223 lr-xr-xr-x 1 root root 33 Aug 25 12:08 /dev/hda4 -> ide/host0/bus0/target0/lun0/part4
224 </pre>
225
226 <p>
227 With <c>devfsd</c>, you can also set the permissions, create new device
228 files, define actions etc. All this is described in the next chapter.
229 </p>
230
231 </body>
232 </section>
233 </chapter>
234 <chapter>
235 <title>Administrating the device tree</title>
236
237 <section>
238 <title>Restarting devfsd</title>
239 <body>
240
241 <p>
242 When you alter the <path>/etc/devfsd.conf</path> file, and you want the
243 changes to be forced onto the system, you don't have to reboot.
244 Depending on what you want, you can use any of the two following
245 signals:
246 </p>
247
248 <p>
249 <b>SIGHUP</b> will have <c>devfsd</c> reread the configuration file,
250 reload the shared objects and generate the REGISTER events for each leaf
251 node in the device tree.
252 </p>
253
254 <p>
255 <b>SIGUSR1</b> will do the same, but won't generate REGISTER events.
256 </p>
257
258 <p>
259 To send a signal, simply use <c>kill</c> or <c>killall</c>:
260 </p>
261
262 <pre caption = "Sending the SIGHUP signal to devfsd">
263 # <i>kill -s SIGHUP `pidof devfsd`</i>
264 <comment>or</comment>
265 # <i>killall -s SIGHUP devfsd</i>
266 </pre>
267
268 </body>
269 </section>
270
271 <section>
272 <title>Removing compatibility symlinks</title>
273 <body>
274
275 <warn>
276 Currently, Gentoo cannot live without the compatibility symlinks.
277 </warn>
278
279 <p>
280 If you want the compatibility symlinks that clutter up <path>/dev</path>
281 removed from your Gentoo system (Gentoo activates it per default), edit
282 <path>/etc/devfsd.conf</path> and remove the following two lines:
283 </p>
284
285 <pre caption = "/etc/devfsd.conf for backwards compatibility">
286 <comment># Comment the following two lines out to remove the symlinks</comment>
287 REGISTER .* MKOLDCOMPAT
288 UNREGISTER .* RMOLDCOMPAT
289 </pre>
290
291 <p>
292 You need to reboot your system for the changes to take affect.
293 </p>
294
295 </body>
296 </section>
297
298 <section>
299 <title>Removing autoload functionality</title>
300 <body>
301
302 <p>
303 When you load a module, devfs will automatically create the device
304 files. If you don't want this behaviour, remove the following line from
305 <path>/etc/devfsd.conf</path>:
306 </p>
307
308 <pre caption = "/etc/devfsd.conf, autoload functionality">
309 LOOKUP .* MODLOAD
310 </pre>
311
312 </body>
313 </section>
314
315 </chapter>
316 <chapter>
317 <title>Permission Related Items</title>
318 <section>
319 <title>Set/change permissions using PAM</title>
320 <body>
321
322 <p>
323 Although you can set permissions in <path>/etc/devfsd.conf</path>, you
324 are advised to use PAM (<e>Pluggable Authentification Modules</e>). This
325 is because PAM has the final say on permissions, possibly ignoring the
326 changes you make in <path>/etc/devfsd.conf</path>.
327 </p>
328
329 <p>
330 PAM uses the <path>/etc/security/console.perms</path> file for the
331 permissions. The file consists of two parts: the first one describes the
332 groups, and the second one the permissions.
333 </p>
334
335 <p>
336 Let's first take a look at the groups part. As an example we view the
337 sound-group:
338 </p>
339
340 <pre caption = "Sound group in /etc/security/console.perms">
341 &lt;sound&gt;=/dev/dsp* /dev/audio* /dev/midi* \
342 /dev/mixer* /dev/sequencer* \
343 /dev/sound/* /dev/snd/* /dev/beep \
344 /dev/admm* \
345 /dev/adsp* /dev/aload* /dev/amidi* /dev/dmfm* \
346 /dev/dmmidi* /dev/sndstat
347 </pre>
348
349 <p>
350 The syntax is quite easy: you start with a group-name, and end with a
351 list of devices that belong to that group.
352 </p>
353
354 <p>
355 Now, groups aren't very usefull if you can't do anything with them. So
356 the next part describes how permissions are handled.
357 </p>
358
359 <pre caption = "Permissions for sound group in /etc/security/console.perms">
360 &lt;console&gt; 0600 &lt;sound&gt; 0600 root.audio
361 </pre>
362
363 <p>
364 The first field is the terminal check. On most systems, this is the
365 console-group. PAM will check this field for every login. If the login
366 happens on a device contained in the console-group, PAM will check and
367 possibly change the permissions on some device files.
368 </p>
369
370 <p>
371 The second field contains the permissions to which a device file is set
372 upon succesfull login. When a person logs into the system, and the device
373 files are owned by a default owner/group, PAM wil change the ownership
374 to the logged on user, and set the permissions to those in this second
375 field. In this case, 0600 is used (user has read/write access,
376 all others don't).
377 </p>
378
379 <p>
380 The third field contains the device-group whose permissions will be
381 changed. In this case, the sound-group (all device files related to
382 sound) will be changed.
383 </p>
384
385 <p>
386 The fourth field defines the permissions to which the device file is set after
387 returning to the default state. In other words, if the person who owns
388 all the device files logs out, PAM will set the permissions back to a
389 default state, described by this fourth field.
390 </p>
391
392 <p>
393 The fifth field defines the ownership (with group if you want) to which
394 the device attributes are set after returning to the default state. In
395 other words, if the person who owns all the device files logs out, PAM
396 will set the ownership back to a default state, described by this fifth
397 field.
398 </p>
399
400 </body>
401 </section>
402
403 <section>
404 <title>Set/change permissions with devfsd</title>
405 <body>
406
407 <p>
408 If you really want to set permissions using
409 <path>/etc/devfsd.conf</path>, then use the syntax used in the following
410 example:
411 </p>
412
413 <pre caption = "Permissions in /etc/devfsd.conf">
414 REGISTER ^cdroms/.* PERMISSIONS root.cdrom 0660
415 </pre>
416
417 <p>
418 The second field is the device group, starting from <path>/dev</path>.
419 It is a regular expression, meaning you can select several device files
420 in one rule.
421 </p>
422
423 <p>
424 The fourth field is the ownership of the device file. Unlike with PAM
425 this isn't changed (unless it is mentioned in <path>console.perms</path>
426 since PAM always wins).
427 </p>
428
429 <p>
430 The fifth field contains the permissions of the device file.
431 </p>
432
433 </body>
434 </section>
435
436 <section>
437 <title>Manually set permissions and have devfsd save it</title>
438 <body>
439
440 <p>
441 This is the default behaviour for Gentoo: if you <c>chown</c> (CHange
442 OWNer) and <c>chmod</c> (CHange MODe) some device files, <c>devfsd</c>
443 will save the information when you are shutting down the system. This is
444 because the <path>/etc/devfsd.conf</path> file contains the following
445 lines:
446 </p>
447
448 <pre caption = "/etc/devfsd.conf for saving permissions">
449 REGISTER ^pt[sy]/.* IGNORE
450 CHANGE ^pt[sy]/.* IGNORE
451 CREATE ^pt[sy]/.* IGNORE
452 DELETE ^pt[sy] IGNORE
453 REGISTER ^log IGNORE
454 CHANGE ^log IGNORE
455 CREATE ^log IGNORE
456 DELETE ^log IGNORE
457 REGISTER .* COPY /lib/dev-state/$devname $devpath
458 CHANGE .* COPY $devpath /lib/dev-state/$devname
459 CREATE .* COPY $devpath /lib/dev-state/$devname
460 DELETE .* CFUNCTION GLOBAL unlink
461 /lib/dev-state/$devname
462 RESTORE /lib/dev-state
463 </pre>
464
465 <p>
466 In other words, changed device files are copied over to
467 <path>/lib/dev-state</path> when shutting down the system, and are
468 copied over to <path>/dev</path> when booting the system.
469 </p>
470
471 <p>
472 Another possibility is to mount <path>/lib/dev-state</path> on
473 <path>/dev</path> at boot-time. To do this, you must make sure that
474 devfs is not mounted automatically (meaning you'll have to recompile
475 your kernel) and that <path>/dev/console</path> exists. Then, somewhere
476 at the beginning of the bootscripts of your system, you place:
477 </p>
478
479 <pre caption = "Mounting /lib/dev-state on top of /dev">
480 mount --bind /dev /lib/dev-state
481 mount -t devfs none /dev
482 devfsd /dev
483 </pre>
484
485 </body>
486 </section>
487 </chapter>
488
489 <chapter>
490 <title>Resources</title>
491 <section>
492 <body>
493
494 <p>
495 For more information on devfs, check out the following resources.
496 </p>
497
498 <p>
499 The devfd.conf manpage explains the syntax of the
500 <path>/etc/devfsd.conf</path> file. To view it, type <c>man
501 devfsd.conf</c>.
502 </p>
503
504 <p>
505 The <uri
506 link="http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html">devfs
507 FAQ</uri> explains everything about devfs. It also contains information
508 about the internal devfs structure and how drivers can support devfs.
509 </p>
510
511 <p>
512 On <uri link="http://www.linuxjournal.com">LinuxJournal</uri> there is
513 an interesting article on <uri
514 link="http://www.linuxjournal.com/article.php?sid=6035">devfs for
515 Management and Administration</uri>.
516 </p>
517
518 <p>
519 Daniel Robbins has written a set of articles for IBM's DeveloperWorks
520 about Advanced filesystems. Three of them are about devfs:
521 </p>
522
523 <ul>
524 <li><uri
525 link="http://www-106.ibm.com/developerworks/linux/library/l-fs4/">Introduction
526 to devfs</uri></li>
527 <li><uri
528 link="http://www-106.ibm.com/developerworks/linux/library/l-fs5/">Setting
529 up devfs</uri></li>
530 <li><uri
531 link="http://www-106.ibm.com/developerworks/linux/library/l-fs6/">Implementing
532 devfs</uri></li>
533 </ul>
534
535 </body>
536 </section>
537 </chapter>
538 </guide>

  ViewVC Help
Powered by ViewVC 1.1.20