I'd just like to reply to this flame war (at the risk of escalating it).
/snip/
I am saying that Albert's statement:
<Begin Quote>
"If you have a static /dev on a normal filesystem, you have to have
all 8 million possible SCSI devices. With devfs, you don't."
<End Quote>
is false. Nothing more nothing less.
/end snip/
I agree. There is absolutely no need to have 8 million inodes at any
time. However, should you at any time happen to want 8 million inodes,
the amount of work involved in MAKEDEVing the lot would be tremendous.
This brings us to the primary advantage of devfs: Ease of use.
Let us consider the average 'man on the street' computer-illiterate
user. To them, the first question will be 'What's a device node?'. This
could require a lengthy answer. However the big advantage devfs offers
to such people is that it is autoconfiguring. It adds/removes nodes
depending on what the device drivers is present, and therefore based
upon the hardware configuration of the system. This obviates the need
for anyone except the hardcore hackers to know 'what's a device node?'.
Anything which makes Linux easier to use, IMHO, is a good thing.
Everything about the Linux kernel can and should be optional (eg.
devfs). If it's optional, it can't annoy anyone. If you don't want it,
don't use it! If you want a problem solved, and don't like the way it
has been solved by others, solve it your own way yourself - ie. let's
see some code. If you don't see it as a problem, then let others solve
their non-problems in peace. Argueing about it gets us nowhere.
Scripts might solve some of the above problems, but devfs is a cleaner
solution to a lot of people. Those who find it messy can write an
alternative. Period.
Let's put devfs in the kernel. It might not help, but it certainly can't
hurt. If it's not your ideal solution, get cracking on your ideal
solution. You can do something akin to what the GGI dudes are doing.
After being rejected big-time by the kernel folks in a war something
akin to this one, they're getting right on with coding in the hope that
somehow, someday, the kernel will contain their code. I don't hear any
people whineing about vesafb (DON'T EVEN THINK ABOUT IT!).
(sheathes a well-worn sword)
:-)
Peter
<LURK FLAMEWAR=off SHIELD=32767 EMAIL_WAR_ALERT=5>
-
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