Messages in this thread | | | Subject | Re: UUIDs (and devfs and major/minor numbers) | Date | Sat, 19 Jun 1999 18:44:11 -0400 | From | Horst von Brand <> |
| |
Nathan Hand <nathanh@chirp.com.au> said: > On Thu, Jun 17, 1999 at 12:49:47PM -0400, Horst von Brand wrote: > > DAVID BALAZIC <david.balazic@uni-mb.si> said: > > > An opinion about /dev : > > > In the old system /dev is a collection of "links" from > > > filenames to device numbers (major:minor).
> > > With devfs it could be a collection of links from > > > filenames to /devfs/* entries.
> > By whom/how are permissions handled? Even if it's symlinks, the original > > files in /devfs have to carry them (you can't follow symplinks to files you > > can't access directly!). And that means the kernel has to know how to set > > up permissions for a new device when it appears, and remember the settings > > from one boot to the next. Gross. And a kludged initscript that sets them > > up on each boot is even worse. As bad as the much-maligned MAKEDEV, but run > > _each_ boot, so much more critical.
> I would like a devfs mounted on /dev which does nothing except report node > accesses that ENODEV to devfsd.
kmod + modprobe are doing fine, thanks.
> Then devfsd can implement all the policies > and naming schemes. Permissions can be handled with /etc/devfs.conf (which > I think is neater than chmod in an ext2 based /dev anyway). The devfsd can > be responsible for node creation with mknod(). Module insert/remove events > can also report to devfsd, preferably with major/minor numbers, so that we > could shove even more policy in devfsd. So perhaps a devfs.conf like
BTW, what do I access to get at the ZIP drive (i.e., today /dev/sda4 on my machine)? It can't be /dev/sda4 if that piece of naming is done by devfsd, which might decide today it's /dev/scsi/ppa/0/4... which obviously doesn't exist until I tell the kernel to go looking for it? OK, I could look it up in a magic place in /proc... but if I don't want to mount proc (perhaps for security reasons, or whatever)? Anyway, now I'm dependent on a magic file in /proc (with _that_ specific format!) that does not exist anywhere else (bye, bye portability) _and_ /dev, and perhaps more stuff. Also, the above might give rise to races.
And "Need Zip drive... OK, look how it should be called today...(root around in /proc)... OK, it's called /dev/foo today, go access /dev/foo so the kernel goes looking for it... nope, not found" sounds harder on the user than "Look for /dev/zip (or whatever it is called _always_ in /dev), if not found give up". Many programs will just go /dev/foo, and introduce subtle bugs.
[...]
> This makes sense to me, and I think moves all policy that Tso and HPA have > been unhappy about completely into a userspace devfsd. I also think it has > the least impact on the existing functionality of devfs (you lose creation > of nodes which don't have devfs.conf entries which might upset proprietary > module developers, but that's about it). It also doesn't meet the proposal > by Tso of providing bus/lun/id information, but I'm not sure that's really > a /dev issue anyway (sounds more like a /proc/hardware/ issue).
The problem with this is that it adds one more program that _must_ work in order for the system to be minimally functional. No devfsd ==> no /usr _at all_, you can't even mount it by hand! And not because the filesystem is shot.
I see all these proposals as introducing complexity for the sake of solving problems that have already been solved (perhaps not with maximal elegance, but with a working solution). Problems that aren't really important in that they need to be addressed perhaps a dozen times during the lifetime of a typical system. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |