>> So with devfs after you have connected a PCMCIA card, in some msec
>> automagically the right devfs device is added to /dev/ or /devfs/?
>
>Yup.
Nice ;-).
>> >Erm, if you just move all block devices into their own subdirectory,
>> >and assuming the bulk of /dev bloat is due to block devices
>> >(reasonable, when you consider the zillions of possible SCSI discs
>> >when we break the 16 disc limit), then searching through /dev/block is
>> >nearly as long as searching /dev with everything in it.
>>
>> With the current inode scheme nobody force you to put all blocks device in
>> the same directory. I will use /tmp/myhd to be fast.
>
>That looks like a hack to me.
Isn' t devfs an hack?
>> And the device-file lookup in the case of block devices is done only at
>> mount time (I hope to be right here ;-) so it' s really not importatnt and
>
>Actually, it's done at open(2) time. That's done by mount(8), fdisk(8)
>and so on. Also if you want to list the directory, it takes more time.
andrea@dragon:/tmp/linux$ ls -lu /sbin/fdisk
-rwxr-xr-x 1 root root 38820 Jul 18 00:57 /sbin/fdisk
18 Jun was the date of my last backup.
>It gets worse if you do "ls -lF" or something, which causes a stat(2)
>of each inode.
I don' t look at /dev/ from ages.
>Mounting isn't the only time you need to access those inodes. Also,
>think about those with a small CPU: extra (noticable!) delay at boot
>time is unwelcome.
We are talking of msec on a 486 with a populated /dev/ I guess.
BTW, with the exciting idea of using btrees for storing directory entries,
the inode lookup will be a lot _faster_.
Richard I had to specify that with my arguments I don' t care at all of
people other than me. I don' t know how much useful can be devfs for
distributors or for people that use Linux only to repartition HDs. I can
tell that devfs is useful for me _only_ for the major/minor numbers thing.
If in the near future there will be a cleaner way to handle >256 minor
numbers devfs will be only overhead _for_me_.
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html