/[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.2 - (hide annotations) (download) (as text)
Thu Sep 11 14:42:52 2003 UTC (10 years, 7 months ago) by swift
Branch: MAIN
Changes since 1.1: +3 -3 lines
File MIME type: application/xml
Fixes some typos

1 swift 1.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 swift 1.2 <date>September 11, 2003</date>
20 swift 1.1 <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 swift 1.2 The second field contains the permissions to which a device file is set
371 swift 1.1 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 swift 1.2 The fourth field defines the permissions to which the device file is set after
386 swift 1.1 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