1 |
<?xml version='1.0' encoding="UTF-8"?> |
2 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/devfs-guide.xml,v 1.10 2005/06/20 09:41:16 neysx Exp $ --> |
3 |
|
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 |
|
20 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
21 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
22 |
<license/> |
23 |
|
24 |
<version>0.5</version> |
25 |
<date>2005-07-18</date> |
26 |
|
27 |
<chapter> |
28 |
<title>What is devfs?</title> |
29 |
<section> |
30 |
<title>The (good?) old days</title> |
31 |
<body> |
32 |
|
33 |
<warn> |
34 |
devfs is <e>obsolete</e> and will eventually be removed from the stable 2.6 |
35 |
tree. Users on 2.6 kernels are hereby advised to switch to udev. For further |
36 |
information on udev, please refer to the <uri |
37 |
link="/doc/en/udev-guide.xml">Gentoo udev Guide</uri>. |
38 |
</warn> |
39 |
|
40 |
<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 |
<pre caption="Checking the information of a device file"> |
65 |
# <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 |
to it: <b>3, 0</b>. This pair is called the <e>major-minor</e> |
73 |
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 |
device. Its major-minor pair is <b>3, 4</b>. In other words, the |
82 |
minor corresponds with the partition where the major corresponds with |
83 |
the device. The second example has <b>4, 5</b> as major-minor |
84 |
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 |
<title>devfs as all-round winner ?</title> |
141 |
<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 |
<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 |
link="udev-guide.xml">udev</uri>, which Gentoo supports and uses by default on |
163 |
most architectures since the 2005.0 release when using a 2.6 kernel. |
164 |
</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 |
</body> |
175 |
</section> |
176 |
</chapter> |
177 |
|
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 |
meaning they both have the same subdirectory structure. |
195 |
</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 |
<pre caption="Directories in /dev"> |
226 |
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 |
<pre caption="Created symlinks"> |
247 |
$ <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 |
|
260 |
<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 |
<pre caption="Sending the SIGHUP signal to devfsd"> |
288 |
# <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 |
Currently, Gentoo cannot live without the compatibility symlinks. |
301 |
</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 |
<pre caption="/etc/devfsd.conf for backwards compatibility"> |
310 |
<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 |
<pre caption="/etc/devfsd.conf, autoload functionality"> |
332 |
LOOKUP .* MODLOAD |
333 |
</pre> |
334 |
|
335 |
</body> |
336 |
</section> |
337 |
</chapter> |
338 |
|
339 |
<chapter> |
340 |
<title>Permission Related Items</title> |
341 |
<section> |
342 |
<title>Set/change permissions with devfsd</title> |
343 |
<body> |
344 |
|
345 |
<note> |
346 |
These instructions are valid as long as pam_console is disabled in |
347 |
<path>/etc/pam.d/system-auth</path>. If you enabled pam_console there, |
348 |
then PAM has the final word on permissions. |
349 |
</note> |
350 |
|
351 |
<p> |
352 |
If you want to set permissions using <path>/etc/devfsd.conf</path>, |
353 |
then use the syntax used in the following example: |
354 |
</p> |
355 |
|
356 |
<pre caption="Permissions in /etc/devfsd.conf"> |
357 |
REGISTER ^cdroms/.* PERMISSIONS root.cdrom 0660 |
358 |
</pre> |
359 |
|
360 |
<p> |
361 |
The second field is the device group, starting from <path>/dev</path>. |
362 |
It is a regular expression, meaning you can select several device files |
363 |
in one rule. |
364 |
</p> |
365 |
|
366 |
<p> |
367 |
The fourth field is the ownership of the device file, and the fifth |
368 |
field contains the permissions of the device file. |
369 |
</p> |
370 |
|
371 |
</body> |
372 |
</section> |
373 |
<section> |
374 |
<title>Manually set permissions and have devfsd save it</title> |
375 |
<body> |
376 |
|
377 |
<p> |
378 |
This is the default behaviour for Gentoo: if you <c>chown</c> (CHange |
379 |
OWNer) and <c>chmod</c> (CHange MODe) some device files, <c>devfsd</c> |
380 |
will save the information so that it will persist across reboots. This |
381 |
is because the <path>/etc/devfsd.conf</path> file contains the |
382 |
following lines: |
383 |
</p> |
384 |
|
385 |
<pre caption="/etc/devfsd.conf for saving permissions"> |
386 |
REGISTER ^pt[sy]/.* IGNORE |
387 |
CHANGE ^pt[sy]/.* IGNORE |
388 |
CREATE ^pt[sy]/.* IGNORE |
389 |
DELETE ^pt[sy] IGNORE |
390 |
REGISTER ^log IGNORE |
391 |
CHANGE ^log IGNORE |
392 |
CREATE ^log IGNORE |
393 |
DELETE ^log IGNORE |
394 |
REGISTER .* COPY /lib/dev-state/$devname $devpath |
395 |
CHANGE .* COPY $devpath /lib/dev-state/$devname |
396 |
CREATE .* COPY $devpath /lib/dev-state/$devname |
397 |
DELETE .* CFUNCTION GLOBAL unlink |
398 |
/lib/dev-state/$devname |
399 |
RESTORE /lib/dev-state |
400 |
</pre> |
401 |
|
402 |
<p> |
403 |
In other words, changed device files are copied over to |
404 |
<path>/lib/dev-state</path> as soon as the change happens, and are |
405 |
copied over to <path>/dev</path> when booting the system. |
406 |
</p> |
407 |
|
408 |
<p> |
409 |
Another possibility is to mount <path>/lib/dev-state</path> on |
410 |
<path>/dev</path> at boot-time. To do this, you must make sure that |
411 |
devfs is not mounted automatically (meaning you'll have to recompile |
412 |
your kernel) and that <path>/dev/console</path> exists. Then, somewhere |
413 |
at the beginning of the bootscripts of your system, you place: |
414 |
</p> |
415 |
|
416 |
<pre caption="Mounting /lib/dev-state on top of /dev"> |
417 |
mount --bind /dev /lib/dev-state |
418 |
mount -t devfs none /dev |
419 |
devfsd /dev |
420 |
</pre> |
421 |
|
422 |
</body> |
423 |
</section> |
424 |
</chapter> |
425 |
|
426 |
<chapter> |
427 |
<title>Resources</title> |
428 |
<section> |
429 |
<body> |
430 |
|
431 |
<p> |
432 |
For more information on devfs, check out the following resources. |
433 |
</p> |
434 |
|
435 |
<p> |
436 |
The devfsd.conf manpage explains the syntax of the |
437 |
<path>/etc/devfsd.conf</path> file. To view it, type <c>man |
438 |
devfsd.conf</c>. |
439 |
</p> |
440 |
|
441 |
<p> |
442 |
The <uri |
443 |
link="http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html">devfs |
444 |
FAQ</uri> explains everything about devfs. It also contains information |
445 |
about the internal devfs structure and how drivers can support devfs. |
446 |
</p> |
447 |
|
448 |
<p> |
449 |
On <uri link="http://www.linuxjournal.com">LinuxJournal</uri> there is |
450 |
an interesting article on <uri |
451 |
link="http://www.linuxjournal.com/article.php?sid=6035">devfs for |
452 |
Management and Administration</uri>. |
453 |
</p> |
454 |
|
455 |
<p> |
456 |
Daniel Robbins has written a set of articles for IBM's DeveloperWorks |
457 |
about Advanced filesystems. Three of them are about devfs: |
458 |
</p> |
459 |
|
460 |
<ul> |
461 |
<li> |
462 |
<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs4/"> |
463 |
Introduction to devfs</uri> |
464 |
</li> |
465 |
<li> |
466 |
<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs5/"> |
467 |
Setting up devfs</uri> |
468 |
</li> |
469 |
<li> |
470 |
<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs6/"> |
471 |
Implementing devfs</uri> |
472 |
</li> |
473 |
</ul> |
474 |
|
475 |
</body> |
476 |
</section> |
477 |
</chapter> |
478 |
</guide> |