> On Thu, 7 Oct 1999, Jakma, Paul wrote:
>
> > > > >Names _are_ policy. So now I have to hack the kernel to
> > > rename the mouse?
> > > >
> > > > No. Used symlinks, which, with devfsd, BTW, are persistent.
> > >
> > > A thought, that I'm sure has been said before, but...
> > >
> > > /devices -- devfs mountpoint
> > > /dev -- symlinks in to /devices
> > >
> >
> > or maybe:
> >
> > /devices -- devfs
> > /dev -- normal /dev.
> >
> > devfsd updates the specials in /dev as and when /devices changes.
>
> Yes, but it'd be nice to somehow handle the issue of running
> out of major,minor pairs, so if we could do what you're suggesting,
> but somehow only have one major,minor used (Or something) that will
> basically say 'go talk to devfs' that'd be nice. Unfortunatly I
> don't have a clue how you'd get that to work...
> You could almost just allocate a block of major,minor's that
> devfs could use and then just start counting from 0 the devices in
> the system. This is kind of ugly though, and when you add something
> in to the system you either break everything, or have devfsd fix it
> all, but then you're back to entries in /dev changing, and the other
> problem of what happens when a major,minor changes while someone has
> it open'ed...
> I guess the problem as I see it is a way to keep what device
> has what dynamically assigned major,minor the same between reboots..
>
This can be handled Solaris style with a slight modification
to devfs. In compatability mode, devfs can report the major and
minor number pairs associated with each device.
This information can be used with a currently hypothetical
"builddev" to populate and verify ownership and
permissions on /dev using device nodes. This does
nothing for the Major/Minor number problem, that still
needs to be dealt with seperately, but it does directly
address most of the remaining objections. It also
provides a place to kill a lot of the /proc pollution
we have been getting since 1.3.x. In addition it obsoletes
/dev/MAKEDEV for systems where it is in use, simplifying
the job of writing a new driver by one step.
For a static system this program only needs to be run
when you would run "boot -r" on Solaris, for a dynamic
system in can be run continually or at every reboot (depending
on the particulars of the system). It can also use either
the devfsd config file, existing permissions in /dev, or
a combination of the two to set permissions.
It allows "policy" for the /dev directory to be set _entirely_
in userspace, it allows dynamic creation _and_removal_
of devices as needed, and it does the jig on Sundays.
Anyone got a problem with this?
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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/