[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [2.4.0] migration to devfs

>>>>> "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

    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>

Reply to: