[gwr quotes and replies to me]
>> Or if devfs does support [ln, chmod, etc], it means the results
>> won't survive the next reboot.
> It is easy enough to make such a thing support changes; it could work
> something like an automatically initialized ramdisk.

> The idea of making the kernel responsible for making its own device
> nodes has some elgance (the kernel knows the right information).

True, but what exactly do you want it to do?  The problem is that the
userland interface to the kernel device tables is small integers, small
integers that for a variety of reasons (not all of which we can change)
vary across ports.

[thorpej replies, again to me]
> ...So, the way Sun "solved" this is to put the devfs on /devices, and
> make /dev into a symlink farm.  Under Solaris, the symlinks
> themselves have permissions, whereas permission of a symlink follows
> that of the real object at the end of the symlink chain in BSD.

> Needless to say, I don't particularly like how Sun did that...

This (which is like my /kern/dev, only calling it /devices instead)
sounds like an elegant idea, in that it provides a kernel-exported
interface based on strings instead of small integers.  The major
problem with it is permissions: either /devices (or /kern/dev, or
whatever) has to support chmod, chown, etc, and some way has to be
provided to preserve such changes across reboots, or else /devices has
to be o-x (to prevent vanilla users from creating their own symlinks to
it), the symlinks out of /dev have to have mode bits of their own, and
these same symlinks have to somehow be able to bust through the
protection on /devices.  Now, I already have code that implements mode
bits on symlinks (though not doing what'd be wanted here) and have been
thinking about setuid and setgid symlinks (they change the effective ID
with which the rest of the path walk is done), but combining them
doesn't solve this problem because you want them owned by one user (for
the permissions checking) and you want them setuid to a potentially
different user (to bull through /devices).

Or else, the kernel has to special-case symlinks from /dev into
/devices, which is even grosser than what we have now.  Jason, do you
know how Solaris resolves this dilemma?

Perry remarks that
> it is possible to combine a devfs with some sort of configuration
> file so that all the changes you list survive across reboots, [...]

...which is about the only place to do it, and it has the disadvantage
that when you chmod something in /dev, you _also_ have to go tweak a
config file to make the change permanent.

Another possible solution occurs to me, stolen from IRIX.  This is to
introduce a mapping table between user-level major numbers and cdevsw[]
(or bdevsw[]) indices.  This would completely solve the major number
unification problem at the price of one array reference, in MI code
using an MD table, per device node lookup.  Ports' device switch tables
would not have to change at all.

I don't really like any of these solutions.  I think the symlinks
answer has the most potential.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B