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.
> -J-

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, 
irresepective of
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. 
This vastly
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
method of
creating devices dynamically has never received overwhelming support
from the
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
the most
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,
and thus
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
the 2.6
series of stable kernels, came a new virtual filesystem called 'sysfs'. 
The job
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
should be
used.  Drivers that have been compiled into the kernel directly,
register their
objects with sysfs as they are detected by the kernel.  For drivers
compiled as
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
just in
case they do.  The 'udevstart' program then walks through the /sys
and creates devices under /dev that match the descriptions.  For
example, the
'/sys/class/tty/vcs/dev' contains the string "7:0".  'udevstart' uses
this to
create /dev/vcs with major number 7 and minor 0.  The permissions of
each and
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
in the
files within the /etc/udev/rules.d/ directory (numbered in the same way
as the
permissions files).

Once the above stage is complete, all devices that are already present
and have
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
new device
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
kernel will
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 -
an access
to the device node causes the appropriate kernel module to load.  With
udev, this
method will not work, because the device node does not exist until the
module is
loaded.  To solve this, we've added another bootscript, S05modules, and
a file
/etc/sysconfig/modules.  By adding module names to the sysconfig file,
one per
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
because it
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
tree.  These
   drivers will not end up having their device nodes created.  You can
use the
   /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
tells the
   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.

Useful reading


More information about the lfs-dev mailing list