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.The solution is an /etc/devfs.conf which sets perms/uids/gids against nodenames. The format being something simple like   /dev/sd/*     0660      root     disk   /dev/sg/*     0660      root     sysIf accesses to the devfs /dev then communicate with devfsd to create nodesthen node creation is in user space so perms can be setup properly.This isn't as "unix-like" as using chmod directly on the node, but I can'tsee a more elegant way of doing it while retaining a virtual /dev.Anyway I hate the tarball hack, so /etc/devfs.conf appeals to me.In fact seeing as MAKEDEV currently implements something rather similar to/etc/devfs.conf anyway, it's not that much of a change.And having a virtual /dev is most of the point of having devfs.I would like a devfs mounted on /dev which does nothing except report nodeaccesses that ENODEV to devfsd. Then devfsd can implement all the policiesand naming schemes. Permissions can be handled with /etc/devfs.conf (whichI think is neater than chmod in an ext2 based /dev anyway). The devfsd canbe responsible for node creation with mknod(). Module insert/remove eventscan also report to devfsd, preferably with major/minor numbers, so that wecould shove even more policy in devfsd. So perhaps a revised devfs.conf   14   3   /dev/dsp   0660   root   soundWith major and minors in the first two columns. This would make all policyexist in user space. The only thing the module needs report to devfsd is amajor/minor pair. Persistence is assured because devfs.conf is stored in afile in /etc which is on ext2. You still have a fully virtual /dev. And itis also possible to access non-existant nodes and have devfsd lookup namesinstead of major/minor numbers to create the node properly. Accessing nodenames 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 havebeen unhappy about completely into a userspace devfsd. I also think it hasthe least impact on the existing functionality of devfs (you lose creationof nodes which don't have devfs.conf entries which might upset proprietarymodule developers, but that's about it). It also doesn't meet the proposalby Tso of providing bus/lun/id information, but I'm not sure that's reallya /dev issue anyway (sounds more like a /proc/hardware/ issue).Is this a fair compromise between devfs/nodevfs parties? I really would behappy if devfs made it into 2.3 but the current stalemate isn't getting itanywhere quickly. I can understand that virtual /dev isn't traditional buttraditional UNIX /dev really can't handle kernel modules and hot pluggablehardware properly. I'd be most interested in hearing HPA and Tso's opinionon this scheme.-- 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" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/