/[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.1 - (show annotations) (download) (as text)
Fri Aug 29 12:15:12 2003 UTC (11 years ago) by swift
Branch: MAIN
File MIME type: application/xml
New devfs guide

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

  ViewVC Help
Powered by ViewVC 1.1.20