/[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.9 - (show annotations) (download) (as text)
Mon Jun 20 08:09:11 2005 UTC (9 years, 3 months ago) by fox2mike
Branch: MAIN
Changes since 1.8: +11 -4 lines
File MIME type: application/xml
#96379, Making the fact that devfs is obsolete quite clear. Thanks to Jan for reporting.

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

  ViewVC Help
Powered by ViewVC 1.1.20