Re: [2.4.0] migration to devfs

[Brian May <bam@debian.org>]

>>>>> "Ethan" == Ethan Benson <erbenson@alaska.net> writes:

    Ethan> On Sat, Jan 06, 2001 at 01:34:07PM -0500, S.Salman Ahmed
    Ethan> wrote:
    >> I have one question regarding devfs: does it offer any
    >> performance improvements over the traditional non-devfs setup,
    >> or is devfs simply a 'structural' change ?

    Ethan> i fail to see how typing:

    Ethan> /dev/ide/host0/bus0/target0/lun0/part1

    Ethan> instead of /dev/hda1 or /dev/wd0a whenever i need to do
    Ethan> anything related to raw devices is a performance

Have a look at Documentation/filesystems/devfs/README, with the Linux
kernel (at least 2.4.0test10) - there are a number of good reasons for
why devfs is required, mentioned there. I recommend anyone interested
in devfs should read this first before posting to this thread.

Also, yes, the first one *could* be a performance gain, because:

"There is an important difference between the way disc-based character
and block nodes and devfs entries make the connection between an entry
in /dev and the actual device driver.

With the current 8 bit major and minor numbers the connection between
disc-based c&b nodes and per-major drivers is done through a
fixed-length table of 128 entries. The various filesystem types set
the inode operations for c&b nodes to {chr,blk}dev_inode_operations,
so when a device is opened a few quick levels of indirection bring us
to the driver file_operations.

For miscellaneous character devices a second step is required: there
is a scan for the driver entry with the same minor number as the file
that was opened, and the appropriate minor open method is called. This
scanning is done *every time* you open a device node. Potentially, you
may be searching through dozens of misc. entries before you find your
open method. While not an enormous performance overhead, this does
seem pointless.

[...]

Note thate devfs doesn't use the major&minor system. For devfs
entries, the connection is done when you lookup the /dev entry. When
devfs_register() is called, an internal table is appended which has
the entry name and the file_operations. If the dentry cache doesn't
have the /dev entry already, this internal table is scanned to get the
file_operations, and an inode is created. If the dentry cache already
has the entry, there is *no lookup time* (other than the dentry scan
itself, but we can't avoid that anyway, and besides Linux dentries
cream other OS's which don't have them:-). Furthermore, the number of
node entries in a devfs is only the number of available device
entries, not the number of *conceivable* entries. Even if you remove
unnecessary entries in a disc-based /dev, the number of conceivable
entries remains the same: you just limit yourself in order to save
space."

    Ethan> improvment.  nor is writing huge kludgy initscripts or
    Ethan> bloated daemons just so i can do:

I also disagree with this statement, too.
-- 
Brian May <bam@debian.org>