lkml.org 
[lkml]   [1999]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.235 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site