Daniel Carosone wrote:

> 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.

I'm really liking the way this sequence of ideas is developing.

> 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.

Hmm, I still like the idea of, for a majority of devices, not having to do
anything in advance, and I like not having ls /dev cluttered with hundreds
of entries irrelevant to my system.  But I don't imagine it would be difficult
to have a hybrid of this idea with the other devfs ideas so that default nodes
could appear without needing magic symlinks.  It looks like the key contribution
of this idea is for the locator-name-space to be not just literal names but
a sort of tiny query language.

I could see, perhaps, such a query syntax being added to config(9) so that
a default complement of nodes could be specified right in the config files
where the devices are defined, and overridden in the site config file just
like other options, and the symdev links using the same syntax.  Maybe part
of the syntax for a symdev link specifies whether it should be an /additional/
name for the device matching the query, or should be the /only/ one and
cancel the default one provided in the kernel config.  To support the second
case one would want to be able to scan for all such links at the time the
devfs is created, to avoid creating the default nodes.  In that case you
might not want to support such links scattered arbitrarily in a filesystem,
but would want to contain them in a known directory or subtree (or make them
not symlinks but entries in a file, still with the same syntax).

-Chap