/[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 - (hide annotations) (download) (as text)
Mon Feb 14 15:57:59 2005 UTC (10 years, 5 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 swift 1.1 <?xml version='1.0' encoding="UTF-8"?>
2 swift 1.8 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/devfs-guide.xml,v 1.7 2004/09/09 11:56:26 swift Exp $ -->
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 swift 1.4 <mail link="swift@gentoo.org">Sven Vermeulen</mail>
10 swift 1.1 </author>
11     <author title="Reviewer">
12 swift 1.4 <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
13 swift 1.1 </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 swift 1.4
20 dertobi123 1.5 <license/>
21    
22 swift 1.8 <version>0.3</version>
23     <date>2005-02-14</date>
24 swift 1.4
25 swift 1.1 <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 swift 1.7 <title>devfs as all-round winner ?</title>
132 swift 1.1 <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 swift 1.7 <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 swift 1.1 </body>
165     </section>
166 swift 1.4 </chapter>
167 swift 1.1
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 swift 1.4
250 swift 1.1 <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 swift 1.4 </chapter>
328 swift 1.1
329     <chapter>
330     <title>Permission Related Items</title>
331     <section>
332 swift 1.8 <title>Set/change permissions with devfsd</title>
333 swift 1.1 <body>
334    
335 swift 1.8 <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 swift 1.1
341     <p>
342 swift 1.8 If you want to set permissions using <path>/etc/devfsd.conf</path>,
343     then use the syntax used in the following example:
344 swift 1.1 </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 swift 1.8 The fourth field is the ownership of the device file, and the fifth
358     field contains the permissions of the device file.
359 swift 1.1 </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 swift 1.8 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 swift 1.1 </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 swift 1.8 <path>/lib/dev-state</path> as soon as the change happens, and are
395 swift 1.1 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 dertobi123 1.5 The devfsd.conf manpage explains the syntax of the
427 swift 1.1 <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 swift 1.4 <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 swift 1.1 </ul>
464    
465     </body>
466     </section>
467     </chapter>
468     </guide>

  ViewVC Help
Powered by ViewVC 1.1.20