--1Dvf9Qz7hFaodvwE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On the issue of namespaces, in one view of a "full devfs", even having
major,minor numbers as a namespace at all should go away, or at least
become a historical distraction.  The device *is* the vnode in the
devfs.

There was a suggestion recently in a thread about cloning devices that
illustrates this, re making specfs change the major, minor numbers in
the returned vnode.  The problem with that, at least for the ptmx
case, is that having the cloned nodes in that namespace at all
potentially exposes various aliasing-type problems where another
normal dev node is created with the same numbers elsewhere.

It's almost certainly my own lack of understanding, but I've also
never been entirely clear and confident that various kinds of locking
done in the vnode vs driver layer for some devices is robust against
such aliasing.

If the only way to refer to the device (or other "object") is via the
open handle, many of these potential confusions are eliminated.  Where
there's an explicit administrative need to get at them via another
path, one can be provided explicity - perhaps as in the case of audio
vs audioctl nodes, and their different opening behaviour.

As for persistence of permissions and other manual settings, I have
yet to see a strong example that can't be solved with something like
an mtree specfile at boot, perhaps combined with a kevent-like
notification to a daemon when new devices appear (perhaps they appear
with 000 by default, to avoid races?)

When there's a master process causing a dev node to appear, as in the
pts case or as with pipes and unix sockets, that process should be
able to specify the perms.

I did, long ago, suggest the unionfs-mounted-under-/dev trick, such as
for holding convenience symlinks and similar things.  I can't help the
feeling that this discussion is making to much of this issue. The
solution needs to be right, but part of being right is being simple.

--
Dan.

--1Dvf9Qz7hFaodvwE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBnVmuEAVxvV4N66cRAmm3AJwMBl+pIZlbuvBsVomtHuKCWWAvEACg078d
LHAC3B+9e761BAI3hTTVVas=
=VPU/
-----END PGP SIGNATURE-----

--1Dvf9Qz7hFaodvwE--