On Mon, Mar 03, 2003 at 12:17:28AM +0000, iriXx wrote:
> im not at all familiar with devfs... it confuses the hell outta me
> actually...!

                    A Quick (Conceptual) Primer on DevFS

        In the tradition of UNIX, Linux exposes hardware devices via
"filenames" located under the /dev directory.  Each of the filenames located
there refers to a particular device.  However, these entries are not real
files (i.e. bytes stored in hard disk blocks), but are specially marked as
"device nodes" which point to kernel drivers.  When a program opens a file,
it checks to see if the file is marked as a device node and, if so, doesn't
pull bytes off the disk, but rather from the kernel driver pointed to by the
device node.

        How does the device node point to a kernel driver?  Through a pair
of 16-bit numbers, called the major and minor device numbers.  You can see
them using 'ls -l':

$ ls -l /dev/null
crw-rw-rw-    1 root     root       1,   3 Dec 31  1969 /dev/null
                                   ^^   ^^
        These are the device numbers.  These numbers are stored in the
device node.  When you open a device, the system reads the device numbers
out of the device node to know which kernel driver to activate.  Note that
the device numbers are what actually matter here.  The *name* of the device
node can be anything.  Thus, you could create a device node named
'/dev/null', but give it the device numbers "14,3" which points to your
audio device's DSP.  (Confuse your enemies!)

        Note that, traditionally, the device node itself is stored on disk,
*regardless* of whether the driver actually exists.  These nodes are created
at install time "just in case" they are needed.  That's why your /dev tree
is populated with hundreds of device names, even if you don't have drivers
for them.  This is wasteful of disk space, as well as very confusing for
users.

        Thus was born DevFS: Device Filesystem.  'devfs' is a filesystem,
like 'vfat' or 'affs'; it presents filenames that may be open()ed, close()d,
ioctl()ed, etc.  Unlike those filesystems, however, 'devfs' isn't backed by
hard disk blocks -- it's entirely virtual, saving disk space (but consuming
RAM.  Oh well...).

        'devfs' has another advantage: There are no unnecessary entries
appearing in a 'devfs' heirarchy.  If an entry appears in 'devfs', that
means there's a kernel driver behind it that has registered its existence
with 'devfs', and is ready to do work.  Thus, you don't see a mess of
hundreds of "dead" device entries.  Only those devices that are actually
present appear in the 'devfs' tree.

        'devfs' is also dynamic.  If a new device becomes available -- such
as by plugging in a new USB peripheral -- a new entry for it will magically
appear in 'devfs'.  When you unplug it, it will magically disappear.

        'devfs' also tries to eliminate the confusing naming scheme that has
plagued UNIX for, well, ever.  /dev/sda1 and /dev/hdb3 are gone, replaced
with the clearly more sensible /dev/scsi/host0/bus0/target0/lun0/part1 and
/dev/ide/host0/bus0/target1/lun0/part3.

        In addition to publishing the device numbers, 'devfs' also allows
kernel drivers to publish the preferred name.  Thus, /dev/null will always
show up as '/dev/null' when it's ready for use.

        While (nearly) all Linux drivers have been re-written to take
advantage of 'devfs', not all applications are devfs-aware.  Thus was born
'devfsd', the "compatibility layer."  'devfsd' (devfs daemon) creates a
bunch of softlinks in the /dev heirarchy with all the old names (/dev/sdb)
pointing to the new names (/dev/scsi/host0/bus0/target1/lun0/disc).  The
exact instructions on how these softlinks are created and what their names
are are defined in /etc/devfs/devfsd.conf, and are (tersely) documented in
the devfsd(8) man page.  Thus, /dev gets all that clutter again, *and* you
get another very confusing thing to configure.

        So, as you see, 'devfs' is dead simple, and more or less looks after
itself.  'devfsd', on the other hand, is a pain in the neck.

                                        Schwab


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Alsa-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to