/[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.9 - (hide annotations) (download) (as text)
Mon Jun 20 08:09:11 2005 UTC (9 years, 2 months ago) by fox2mike
Branch: MAIN
Changes since 1.8: +11 -4 lines
File MIME type: application/xml
#96379, Making the fact that devfs is obsolete quite clear. Thanks to Jan for reporting.

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

  ViewVC Help
Powered by ViewVC 1.1.20