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

In the spirit of throwing out ideas to see what sticks, here's another.

Part of the problem with dev nodes currently is that the alternate
major/minor namespace is too.. limited? constricted? static?

Perhaps we need a new dev node type, that can act like a /dev node now
but store more appropriate references to the intended driver and
instance.

For the sake of simplicity and illustration, consider a kind of "magic
symlink", lets call them "symbolic devices". Apollo Domain/OS used to
have a special syntax within the link target text for expanding the
link differently depending on which "universe" you were in, so you got
(eg) the SYSV or BSD ps(1). Let's hypothesize a similar link syntax,
or a separate symlink variant, that allows links to "device locator
paths".

That addresses one part of the devfs requirement: wiring names to
locators.  The form of these locators needs to be carefully chosen,
for example so that FC-AL disks are not tied to PCI and HBA paths, or
umass devices to usb ports, of course. However, by making them "magic
symlinks" rather than actual symlinks to an actual devfs tree
resembling solaris' /devices, we allow the possibility of smarter
links.  Link text might include the possibility of wildcard locators,
for example.

The locator-string namespace may be similar, but not quite like, an
actual filesystem.  Devices would register themselves into this
namespace at attach time, and might be found via a number of locators
or aliases (eg, wedge volume names from various label formats).

Processing of such symlinks would be disabled if the filesystem that
contained them was mounted -o nosymdev. Processing of normal /dev
nodes vs -o nodev would continue as now.  That lets you choose between
styles of device access, even from different parts of the filesystem
(ie, within or outside a chroot).  Permissions on the symlink would be
honoured in order to follow it, in the same way as perms on c or b
nodes are now.

The second part of the requirement is for nodes to appear in /dev
automatically when driver instances are created, such as in the pts
case.  Perhaps this need is diminished if suitable "magic symlinks"
are in place ahead of time, with appropriate wildcards - following
them when the locator can't be matched returns ENXIO, as now.

In other words, perhaps devfs isn't so much a full filesystem, but
simply a way of resolving "smarter" /dev entries in a normal
filesystem to device locators.

Does factoring the problem in this way help simplify any of the other
design problems?

--
Dan.
--ByM1h5nouWwd3kz8
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBnpCDEAVxvV4N66cRAnjdAJ4iRE+QCg/M2wj4owPKq6SQoJOo+ACeKIM+
HoMxQUZks4dyejQiY+EZiks=
=tA25
-----END PGP SIGNATURE-----

--ByM1h5nouWwd3kz8--