/[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.8 - (show annotations) (download) (as text)
Mon Feb 14 15:57:59 2005 UTC (9 years, 7 months ago) by swift
Branch: MAIN
Changes since 1.7: +17 -101 lines
File MIME type: application/xml
#81850 - No references to PAM, we are pushing it out

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

  ViewVC Help
Powered by ViewVC 1.1.20