/[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.15 - (show annotations) (download) (as text)
Thu Nov 15 22:41:08 2007 UTC (7 years ago) by nightmorph
Branch: MAIN
Changes since 1.14: +10 -7 lines
File MIME type: application/xml
update devfs guide with pam_console's deprecation and removal. good lord, the doc hadn't been touched in two years and four months.

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

  ViewVC Help
Powered by ViewVC 1.1.20