The solution is an /etc/devfs.conf which sets perms/uids/gids against node
names. The format being something simple like
/dev/sd/* 0660 root disk
/dev/sg/* 0660 root sys
If accesses to the devfs /dev then communicate with devfsd to create nodes
then 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't
see 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 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 revised devfs.conf
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).
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. I'd be most interested in hearing HPA and Tso's opinion
on 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" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/