/[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.18 - (hide annotations) (download) (as text)
Sun Sep 4 17:53:40 2011 UTC (3 years, 2 months ago) by swift
Branch: MAIN
CVS Tags: HEAD
Changes since 1.17: +2 -2 lines
File MIME type: application/xml
#379883 - Removing link attribute from guide element as it is not used anymore. Next step will be to remove it from DTD

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

  ViewVC Help
Powered by ViewVC 1.1.20