Messages in this thread | | | Date | Wed, 9 Jun 1999 03:26:02 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
On Tue, 8 Jun 1999, Matthew Kirkwood wrote:
> > 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/
| |