doc/en/devfs-guide.xml

<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/devfs-guide.xml,v 1.12 2005/07/21 15:30:05 neysx Exp $ -->

<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

<guide link="/doc/en/devfs-guide.xml">
<title>Device File System Guide</title>
<author title="Author">
  <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
</author>
<author title="Reviewer">
  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
</author>

<abstract>
In this document you'll find information on what devfs is really about
and how to work with it.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>0.7</version>
<date>2006-11-28</date>

<chapter>
<title>What is devfs?</title>
<section>
<title>The (good?) old days</title>
<body>

<warn>
devfs is <e>obsolete</e> and has been removed from the stable 2.6 tree in the
2.6.13 release. Users on 2.6 kernels are hereby advised to switch to udev. For
further information on udev, please refer to the <uri
link="/doc/en/udev-guide.xml">Gentoo udev Guide</uri>.
</warn>

<p>
Traditional Linux implementations provide their users with an
abstract device path, called <path>/dev</path>. Inside this path the
user finds <e>device nodes</e>, special files that represent devices
inside their system. For instance, <path>/dev/hda</path> represents the
first IDE device in their system. By providing device files to the
users, they can create programs that interact with hardware as if the
hardware was a regular file instead of using special APIs.
</p>

<p>
The device files are split in two groups, called <e>character</e>
devices and <e>block</e> devices. The first group consists of hardware
of which read/writes are not buffered. The second group naturally
consists of hardware of which read/writes are buffered. Both devices can
be read one character at a time, or in blocks. Therefore, the naming
might sound confusing and in fact is wrong.
</p>

<p>
If you take a look at a certain device file, you might find something
like this:
</p>

<pre caption="Checking the information of a device file">
# <i>ls -l /dev/hda</i>
brw-rw----    1 root     disk       3,   0 Jul  5  2000 /dev/hda
</pre>

<p>
In the previous example we see that <path>/dev/hda</path> is a block
device. However, more importantly, it has two special numbers assigned
to it: <b>3, 0</b>. This pair is called the <e>major-minor</e>
pair. It is used by the kernel to map a device file to a real device.
The major corresponds with a certain device, the minor with a subdevice.
Seems confusing? It isn't.
</p>

<p>
Two examples are <path>/dev/hda4</path> and <path>/dev/tty5</path>. The
first device file corresponds with the fourth partition on the first IDE
device. Its major-minor pair is <b>3, 4</b>. In other words, the
minor corresponds with the partition where the major corresponds with
the device. The second example has <b>4, 5</b> as major-minor
pair. In this case, the major corresponds with the terminal driver,
while the minor corresponds with the terminal number (in this case, the
fifth terminal).
</p>

</body>
</section>
<section>
<title>The problems</title>
<body>

<p>
If you do a quick check in such a <path>/dev</path>, you'll find out
that not only all your devices are listed, but <e>all</e> possible
devices that you can imagine. In other words, you have device files for
devices you don't have. Managing such a device group is cumbersome to
say the least. Imagine having to change the permissions of all device
files that have a corresponding device in your system, and leaving the
rest of the device files as they are.
</p>

<p>
When you add new hardware to your system, and this hardware didn't have
a device file previously, you would have to create one. Advanced users know
that this task can be accomplished with <c>./MAKEDEV</c> inside the
<path>/dev</path> tree, but do you immediately know what device you have
to create?
</p>

<p>
When you have programs interacting with hardware using the device files,
you can't have the root partition mounted read only, while there is no
further need to have it mounted read-write. And you can't have
<path>/dev</path> on a seperate partition, since <c>mount</c> needs
<path>/dev</path> to mount partitions.
</p>

</body>
</section>
<section>
<title>The solutions</title>
<body>

<p>
As you can imagine, the kernel hackers have found quite a number of
solutions to the aforementioned problems. However, many of them had
other flaws as described in
<uri>http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why</uri>.
We are not going to talk about these implementations, but focus on the
one implementation that did make it to the official kernel sources:
devfs.
</p>

</body>
</section>
<section>
<title>devfs as all-round winner ?</title>
<body>

<p>
devfs tackles all listed problems. It only provides the user with
existing devices, adds new nodes when new devices are found, and makes
it possible to mount the root filesystem read only. And it tackles more
problems we haven't discussed previously because they are less
interesting for users...
</p>

<p>
For instance, with devfs, you don't have to worry about major/minor
pairs. It is still supported (for backwards compatibility), but isn't
needed. This makes it possible for Linux to support even more devices,
since there are no limits anymore (numbers always have boundaries :)
</p>

<p>
Yet devfs does come with it's own problems; for the end users these issues
aren't really visible, but for the kernel maintainers the problems are big
enough to mark devfs <e>obsolete</e> in favor of <uri
link="udev-guide.xml">udev</uri>, which Gentoo supports and uses by default on
most architectures since the 2005.0 release when using a 2.6 kernel. 
</p>

<p>
For more information as to why devfs is marked obsolete, please read the <uri
link="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ">udev
FAQ</uri> and <uri
link="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs">udev
versus devfs document</uri>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Navigating through the device tree</title>
<section>
<title>Directories</title>
<body>

<p>
One of the first things you might notice is that devfs uses directories
to group devices together. This improves readability, as now all related
devices are inside a common directory.
</p>

<p>
For instance, all IDE-related devices are inside the
<path>/dev/ide/</path> device directory, and SCSI-related devices are inside
<path>/dev/scsi/</path>. SCSI and IDE disks are seen in the same way,
meaning they both have the same subdirectory structure. 
</p>

<p>
IDE and SCSI disks are controlled by an adapter (on-board or a seperate
card), called the <e>host</e>. Every adapter can have several channels.
A channel is called a <e>bus</e>. On each channel, you can have several
IDs. Such an ID identifies a disk. This ID is called the <e>target</e>.
Some SCSI devices can have multiple luns (<e>Logical Unit Numbers</e>),
for instance devices that handle multiple media simultaneously (hi-end
tapedrives). You mostly have only a single lun, <path>lun0/</path>.
</p>

<p>
So, whereas <path>/dev/hda4</path> was used previously, we now have
<path>/dev/ide/host0/bus0/target0/lun0/part4</path>. This is far more
easy... no, don't argue with me... it <e>is</e> easier... ah whatever!
:)
</p>

<note>
You can also use more Unix-like device file naming for hard disks, such as
<path>c0b0t0u0p2</path>. They can be found in <path>/dev/ide/hd</path>,
<path>/dev/scsi/hd</path> etc.
</note>

<p>
To give you an idea on the directories, this is a listing of the
directories which I have on my laptop:
</p>

<pre caption="Directories in /dev">
cdroms/     cpu/        discs/          floppy/
ide/        input/      loop/           misc/
netlink/    printers/   pts/            pty/
scsi/       sg/         shm/            sound/
sr/         usb/        vc/             vcc/
</pre>

</body>
</section>
<section>
<title>Backwards compatibility using devfsd</title>
<body>

<p>
Using this new scheme sounds fun, but several tools and programs make
use of the previous, old scheme. To make sure no system is broken,
<c>devfsd</c> is created. This daemon creates symlinks with the old
names, pointing to the new device files.
</p>

<pre caption="Created symlinks">
$ <i>ls -l /dev/hda4</i>
lr-xr-xr-x    1 root     root           33 Aug 25 12:08 /dev/hda4 -> ide/host0/bus0/target0/lun0/part4
</pre>

<p>
With <c>devfsd</c>, you can also set the permissions, create new device
files, define actions etc. All this is described in the next chapter.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Administrating the device tree</title>
<section>
<title>Restarting devfsd</title>
<body>

<p>
When you alter the <path>/etc/devfsd.conf</path> file, and you want the
changes to be forced onto the system, you don't have to reboot.
Depending on what you want, you can use any of the two following
signals:
</p>

<p>
<b>SIGHUP</b> will have <c>devfsd</c> reread the configuration file,
reload the shared objects and generate the REGISTER events for each leaf
node in the device tree.
</p>

<p>
<b>SIGUSR1</b> will do the same, but won't generate REGISTER events.
</p>

<p>
To send a signal, simply use <c>kill</c> or <c>killall</c>:
</p>

<pre caption="Sending the SIGHUP signal to devfsd">
# <i>kill -s SIGHUP `pidof devfsd`</i>
<comment>or</comment>
# <i>killall -s SIGHUP devfsd</i>
</pre>

</body>
</section>
<section>
<title>Removing compatibility symlinks</title>
<body>

<warn>
Currently, Gentoo cannot live without the compatibility symlinks. 
</warn>

<p>
If you want the compatibility symlinks that clutter up <path>/dev</path>
removed from your Gentoo system (Gentoo activates it per default), edit
<path>/etc/devfsd.conf</path> and remove the following two lines:
</p>

<pre caption="/etc/devfsd.conf for backwards compatibility">
<comment># Comment the following two lines out to remove the symlinks</comment>
REGISTER        .*  MKOLDCOMPAT
UNREGISTER      .*  RMOLDCOMPAT
</pre>

<p>
You need to reboot your system for the changes to take affect.
</p>

</body>
</section>
<section>
<title>Removing autoload functionality</title>
<body>

<p>
When you load a module, devfs will automatically create the device
files. If you don't want this behaviour, remove the following line from
<path>/etc/devfsd.conf</path>:
</p>

<pre caption="/etc/devfsd.conf, autoload functionality">
LOOKUP      .*  MODLOAD
</pre>

</body>
</section>
</chapter>

<chapter>
<title>Permission Related Items</title>
<section>
<title>Set/change permissions with devfsd</title>
<body>

<note>
These instructions are valid as long as pam_console is disabled in
<path>/etc/pam.d/system-auth</path>. If you enabled pam_console there,
then PAM has the final word on permissions.
</note>

<p>
If you want to set permissions using <path>/etc/devfsd.conf</path>,
then use the syntax used in the following example:
</p>

<pre caption="Permissions in /etc/devfsd.conf">
REGISTER    ^cdroms/.*  PERMISSIONS root.cdrom 0660
</pre>

<p>
The second field is the device group, starting from <path>/dev</path>.
It is a regular expression, meaning you can select several device files
in one rule.
</p>

<p>
The fourth field is the ownership of the device file, and the fifth
field contains the permissions of the device file.
</p>

</body>
</section>
<section>
<title>Manually set permissions and have devfsd save it</title>
<body>

<p>
This is the default behaviour for Gentoo: if you <c>chown</c> (CHange
OWNer) and <c>chmod</c> (CHange MODe) some device files, <c>devfsd</c>
will save the information so that it will persist across reboots. This
is because the <path>/etc/devfsd.conf</path> file contains the
following lines:
</p>

<pre caption="/etc/devfsd.conf for saving permissions">
REGISTER        ^pt[sy]/.*   IGNORE
CHANGE          ^pt[sy]/.*   IGNORE
CREATE          ^pt[sy]/.*   IGNORE
DELETE          ^pt[sy]      IGNORE
REGISTER        ^log         IGNORE
CHANGE          ^log         IGNORE
CREATE          ^log         IGNORE
DELETE          ^log         IGNORE
REGISTER        .*           COPY    /lib/dev-state/$devname $devpath
CHANGE          .*           COPY    $devpath /lib/dev-state/$devname
CREATE          .*           COPY    $devpath /lib/dev-state/$devname
DELETE          .*           CFUNCTION GLOBAL unlink
/lib/dev-state/$devname
RESTORE         /lib/dev-state
</pre>

<p>
In other words, changed device files are copied over to
<path>/lib/dev-state</path> as soon as the change happens, and are
copied over to <path>/dev</path> when booting the system.
</p>

<p>
Another possibility is to mount <path>/lib/dev-state</path> on
<path>/dev</path> at boot-time. To do this, you must make sure that
devfs is not mounted automatically (meaning you'll have to recompile
your kernel) and that <path>/dev/console</path> exists. Then, somewhere
at the beginning of the bootscripts of your system, you place:
</p>

<pre caption="Mounting /lib/dev-state on top of /dev">
mount --bind /dev /lib/dev-state
mount -t devfs none /dev
devfsd /dev
</pre>

</body>
</section>
</chapter>

<chapter>
<title>Resources</title>
<section>
<body>

<p>
For more information on devfs, check out the following resources.
</p>

<p>
The devfsd.conf manpage explains the syntax of the
<path>/etc/devfsd.conf</path> file. To view it, type <c>man
devfsd.conf</c>.
</p>

<p>
The <uri
link="http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html">devfs
FAQ</uri> explains everything about devfs. It also contains information
about the internal devfs structure and how drivers can support devfs.
</p>

<p>
On <uri link="http://www.linuxjournal.com">LinuxJournal</uri> there is
an interesting article on <uri
link="http://www.linuxjournal.com/article.php?sid=6035">devfs for
Management and Administration</uri>.
</p>

<p>
Daniel Robbins has written a set of articles for IBM's DeveloperWorks
about Advanced filesystems. Three of them are about devfs:
</p>

<ul>
  <li>
    <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs4/">
    Introduction to devfs</uri>
  </li>
  <li>
    <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs5/">
    Setting up devfs</uri>
  </li>
  <li>
    <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs6/">
    Implementing devfs</uri>
  </li>
</ul>

</body>
</section>
</chapter>
</guide>
1	swift	1.1	<?xml version='1.0' encoding="UTF-8"?>
2	nightmorph	1.13	<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/devfs-guide.xml,v 1.12 2005/07/21 15:30:05 neysx 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	nightmorph	1.13	<mail link="sven.vermeulen@siphos.be">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	nightmorph	1.13	<version>0.7</version>
25			<date>2006-11-28</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			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			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	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			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	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	swift	1.8	<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	swift	1.1
351			<p>
352	swift	1.8	If you want to set permissions using <path>/etc/devfsd.conf</path>,
353			then use the syntax used in the following example:
354	swift	1.1	</p>
355
356	neysx	1.10	<pre caption="Permissions in /etc/devfsd.conf">
357	swift	1.1	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	swift	1.8	The fourth field is the ownership of the device file, and the fifth
368			field contains the permissions of the device file.
369	swift	1.1	</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	swift	1.8	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	swift	1.1	</p>
384
385	neysx	1.10	<pre caption="/etc/devfsd.conf for saving permissions">
386	swift	1.1	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	swift	1.8	<path>/lib/dev-state</path> as soon as the change happens, and are
405	swift	1.1	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	neysx	1.10	<pre caption="Mounting /lib/dev-state on top of /dev">
417	swift	1.1	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	dertobi123	1.5	The devfsd.conf manpage explains the syntax of the
437	swift	1.1	<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	swift	1.4	<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	swift	1.1	</ul>
474
475			</body>
476			</section>
477			</chapter>
478			</guide>