Messages in this thread | | | Date | Sun, 20 Jun 1999 01:05:11 +1000 | From | Nathan Hand <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
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. 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
14 3 /dev/dsp 0660 root sound ...
With major and minors in the first two columns. This would make all policy exist in user space. The only thing the module needs report to devfsd is a major/minor pair. Persistence is assured because devfs.conf is stored in a file in /etc which is on ext2. You still have a fully virtual /dev. And it is also possible to access non-existant nodes and have devfsd lookup names instead of major/minor numbers to create the node properly. Accessing node names or major/minor pairs which aren't listed in devfs.conf just fail.
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).
It doesn't introduce dynamic major/minors, so causes the least problems to NFS. It doesn't impose device naming schemes in the kernel. It doesn't put the mapping between names and major/minors in the kernel. It does give you a completely virtual /dev. It does preserve permissions across reboot with no nasty hacks (though chmod on devfs would need to be disabled).
Is this a fair compromise between devfs/nodevfs parties? I really would be happy if devfs made it into 2.3 but the current stalemate isn't getting it anywhere quickly. I can understand that virtual /dev isn't traditional but traditional UNIX /dev really can't handle kernel modules and hot pluggable hardware properly.
-- Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$ Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
- 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/
| |