>>>>> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
