> > devfs is a good thing. I and all the rest who have tried it and use it
> > regularly think so.
>
> And those of us who tried it and decided that it's the wrong solution to a
> set of non-problems think otherwise.
My one concern is SCSI device management. Under the current
setup it can be challenging to deal with at best. I tend to know what
controller and what target a device is, and that at least is constant if
one disk happens to die. If /dev/sdb dies then everything past that moves,
and the machine won't even boot, even if /dev/sdb is unimportant, if
/dev/sdc is /usr, and it's now /dev/sdb, that gets really painful really
quickly.
> > It's compatible, it's clean, it eliminates /dev admin maintenance.
>
> What /dev admin maintenance? Perhaps my machines don't have enough disks,
> but I have never needed to perform significant work in /dev.
I havn't had to do much in /dev, except when I have to add
devices because they don't come pre-configured in my distribution. That
can be a real pain for users who have never had to work with /dev/MAKEDEV
or mknod, etc. Also, having thousands of things in /dev seems to me at
least not the best solution. Perhaps doing the same kind of thing but in
user space would work, but it seems some of the abilities would be lost,
though to some extent it would be nice to have hardware at a guarenteed
location, and then symlinks to the hardware in the /dev tree, so that even
if I controller is removed the drives on the second controller would appear
at the same place as opposted to being picked up as the drives on the
first controller...
Stephen
-
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.tux.org/lkml/