Simply having inodes with device info (Major/minor devices) incurrs a
penalty in that you have these inodes on a filesystem on disk (or maybe
RAM), in any case you are busying up yet another subsystem, and so
on. devfs is a shorter route to access devices, and this improves (on
some large scale systems) performance when you have a zillion
pseudodevices and you are accessing them a lot. Even if you give me
"Dcache speeds that up", I can say, well, that's only true while the
entries are in the dcache.
Think of having proc be a collection of physical directories with
physical files on disk. I know, this is not an exactly similar idea, but
the devfs shares some procfs-like goodies...
This is, of course, not to mention that device files only exist if they
are really there... Imagine, just
if [ -r /devfs/ide/hd/blah ]; then
echo "you have an ide disk"
fi
if [ -d /dev/fs/ide/cd ]; then
echo "you have a cdrom [or support for one]"
fi
or something like that... It's VERY NICE from a system management POV. I
can't wait to see what distributions do with it.
> I had to say that I never tried devfs and that it could be a very
> confortable workaround but I can' t like it ;-). Probably I' ll try soon
> though. I' m afraid to say this again and after the sure good work of
> Richard...
Well, I cannot gaurantee the total correctness of exactly everything I
claim, but I do understand that the devfs is a shortcut from userspace to
devices. This is a "Good Thing" (tm), in my book.
-Shawn
<=========== America Held Hostage ===========>
Day 2022 for the poor and the middle class.
Day 2041 for the rich and the dead.
900 days remaining in the Raw Deal.
<============================================>
-
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