/[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 - (hide annotations) (download) (as text)
Sat Nov 15 00:35:18 2003 UTC (10 years, 11 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 swift 1.1 <?xml version='1.0' encoding="UTF-8"?>
2 neysx 1.3 <!-- $Header$ -->
3 swift 1.1
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 swift 1.2 <date>September 11, 2003</date>
21 swift 1.1 <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 swift 1.2 The second field contains the permissions to which a device file is set
372 swift 1.1 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 swift 1.2 The fourth field defines the permissions to which the device file is set after
387 swift 1.1 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