> There' s no need of the many config option you added. You don' t need to
> add config option at all. Applying the devfs patch should result in a
> completly different device scheme. Why to not use devfs at all (breaking
> old names and so on) if it would work far better?
I like the config options. They allow you to determine just how you want
things to behave. It seems intuitave to me...
> Another very messy and ugly thing of devfs is the need to handle a tarball
> at every shutdown and bootup.
Ahhh, cmon, that's not too bad. I mean, it is an entirely new way of
keeping track of devices, and the tar thing is a VERY minor tradeoff.
> The only useful thing of devfs is the workaround of the device drivers
> kdev_t numer without have to play with userlevel code. The only people
> that you replyed "use devfs to do that" was asking about how to handle >
> 16SCSI disk.
No, you state below that this is not the case. Auto device generation is
EXTREMELY nice, and I for one like it.
> devfs could result nice since it autodetect every device driver in the
> kernel and in hardware but note that nobody other than people that is
> playing with devfs run a ls in /dev/. The last time I had to do something
> /dev/ related (but I probably I have not run a ls /dev/) was on:
I represent a vast number of people using/liking/wanting devfs in the tree
simply as an option. IMHO, it's the way UNIX should have done it in the
first place.
-Shawn
<=========== America Held Hostage ===========>
Day 2023 for the poor and the middle class.
Day 2042 for the rich and the dead.
899 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