Fwd: Blockers for printed book
Jeremy Utley (-J-), LFS Staff
jeremy at linuxfromscratch.org
Tue Aug 3 22:33:18 PDT 2004
On Tue, 2004-08-03 at 12:53, Jeremy Utley (-J-), LFS Staff wrote:
> > On Tue, 2004-08-03 at 13:19, Jeremy Utley wrote:
> >> I think I have the best understanding of udev and the issues with it of
> >> any of us on the editorial staff - I can do this unless someone else
> >> wants
> >> to step up to it.
> > When can you have it ready by? Don't forget the Binutils explanation.
> > Btw, as an update: All edits are put in now, I'm going back to fix up
> > all the short descriptions and make those short sentences sound better
> > where it can.
> > Things are shaping up nicely, just a few more things to take care of.
> > I'll do a SVN commit soon to get what i have now into it.
> I'll hit both binutils and the udev stuff tonite when I get home from
> work, assuming I don't get to it while between calls at work. Shouldn't
> be too hard to take care of.
OK, the updated udev documentation is finished. I'd appreciate any/all
of you to check for grammar, syntax, or other mistakes I may have made
as I wrote this. I'm attaching the doc inline, rather than as an
attachment - this should make it easier to report mistakes
Device & Module handling on an LFS system
In chapter 6, we installed the udev package. Before we go into the
regarding how this does its job, a brief history of previous methods of
devices is in order.
Linux systems in general traditionally use a static device creation
whereby a whole slew of device nodes are created under /dev,
whether the corresponding hardware devices are physically present in
computer in question. This is typically done via a MAKEDEV script (or
which just contains a number of calls to the 'mknod' program with the
major and minor device numbers for each device. As one of LFS' aims is
provide a relatively small system, we have decided to adopt a different
approach, namely dynamic device creation. Under this method, only those
which are detected by the kernel get device nodes created for them.
decreases the output produced from, for example, 'ls /dev'.
In Febraury, 2000, a new filesystem called 'devfs' was merged into the
kernel, and hence was made generally available during the 2.4 series of
kernels. Although it was present in the kernel source itself, this
creating devices dynamically has never received overwhelming support
core kernel developers. The main problems with the approach adopted by
were seen to be that it handled device detection, creation and naming
all in the
one place. The latter issue, that of device node naming, was perhaps
critical. It is generally accepted that if you are to allow device
names to be
configurable then the device naming policy should be up to a system
administrator, not imposed upon them by any particular developer(s).
also suffers from some race conditions that are inherent in its design,
unavoidable without a considerable rewrite. It has also been marked as
due to a lack of recent maintenance.
With the development of the unstable 2.5 kernel tree, later released as
series of stable kernels, came a new virtual filesystem called 'sysfs'.
of sysfs is to export a view of the system's structure to userspace
With this userspace visible representation, the possibility of seeing a
userspace replacement for devfs became much more realistic.
So, now that you know a bit of the history and rationale behind using a
device setup under Linux, we'll now address the topic of _how_ it
The sysfs filesystem was mentioned briefly above. One may wonder how
knows about the devices present in a system, and what device numbers
used. Drivers that have been compiled into the kernel directly,
objects with sysfs as they are detected by the kernel. For drivers
modules, this will happen when the module is loaded. Once the sysfs
is mounted (on /sys), then all of the data, which the builtin drivers
with sysfs, are now available to userspace processes.
Now that the data is available for udev to create devices from, it's
time it was
called into action. This is done via the S10udev initscript. The first
this script does is registers /sbin/udev as a hotplug event handler.
events shouldn't be generated during this stage, but it's registered
case they do. The 'udevstart' program then walks through the /sys
and creates devices under /dev that match the descriptions. For
'/sys/class/tty/vcs/dev' contains the string "7:0". 'udevstart' uses
create /dev/vcs with major number 7 and minor 0. The permissions of
every device that udevstart creates are set using files under the
/etc/udev.d/permissions.d/ directory. These are numbered in a similar
to our bootscripts. If udev can't find a permissions file for the
device it is
creating, it will default to 600 and root:root. The names of the nodes
under the /dev directory are configured according to the rules specified
files within the /etc/udev/rules.d/ directory (numbered in the same way
Once the above stage is complete, all devices that are already present
compiled-in drivers will be available for use. So, what about those
that have modular drivers?
We mentioned earlier the concept of a "hotplug event handler". When a
connection is detected by the kernel, the kernel will generate a hotplug
and look at the file /proc/sys/kernel/hotplug to find out the userspace
to handle that device connection. Since in the udev initscript we
udev as this handler, when these hotplug events are generated, the
cause udev to walk the /sys filesystem once again, looking for the new
and creating the dev entry for it.
This brings us to one problem that exists with udev, and likewise with
before it, commonly referred to as the "chicken and egg" problem. Most
distrubtions handle loading modules via entries in /etc/modules.conf -
to the device node causes the appropriate kernel module to load. With
method will not work, because the device node does not exist until the
loaded. To solve this, we've added another bootscript, S05modules, and
/etc/sysconfig/modules. By adding module names to the sysconfig file,
line, these modules will be loaded at bootup, allowing udev to detect
One thing to note is that on slower machines, or for drivers that create
a lot of
device nodes, the process of creating devices may take a few seconds to
meaning that some device nodes may not be immediately accessible.
Handling hotpluggable/dynamic devices
When you plug in a device, e.g. a USB MP3 player, the kernel recognises
the device is now connected and generates a hotplug event. As the
bootscript previously set the hotplug event handler to /sbin/udev, this
is what will
process such events. The driver will already have been loaded (either
was compiled into the kernel, or it was loaded via the S05modules
bootscript) so udev
will simply be called upon to create the relevant device node according
to the sysfs
data available in /sys.
Problems with creating devices
1) A kernel driver may not export its data to sysfs
This is most common with 3rd party drivers from outside the kernel
drivers will not end up having their device nodes created. You can
/etc/sysconfig/createfiles configuration file to manually create the
You may end up consulting the devices.txt file inside your kernel
or the documentation for that driver, to find the proper major/minor
2) A non-hardware device is required. This is most common with the ALSA
OSS compatibility module. These types of devices can be handled in
one of 2 ways:
a) Adding the module names to /etc/sysconfig/modules
b) Use of an "install" line in /etc/modprobe.conf - basically, this
modprobe command "when loading this module, also load this other
module, at the
same time." For example:
install snd-pcm modprobe -i snd-pcm ; modprobe snd-pcm-oss ; true
This will cause the system to load both the snd-pcm and snd-pcm-oss
when any request
is made to load the driver snd-pcm.
More information about the lfs-dev