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/