>> # mv /dev/tty00 /dev/foo
>> # mv /dev/tty01 /dev/tty00
>> # mv /dev/foo /dev/tty01
>> how does that get represented?  (Yes, such things have their uses.)
> [...] that brings up another point I've been seeing over and over in
> this thread - we want all of our saved attribute and device name data
> to be stable across autoconfig in the face of environment changes
> that could affect autoconfig order.  It seems worth making an eensy
> weensy point that, as far as I can tell, *there are only two
> fundamental ways of doing that.*  You either let the kernel map from
> locators to your intended assigned names, as by constraining
> autoconfig so it knows the locators of the devices you care about and
> always gives them the names you want, or you make locator-based
> canonical names visible in userland and do your own mapping to your
> favorite names there.  There are different ways to go about either
> approach, but those are the two columns on the menu.

Well, there's a third one, which maps from device-tree stuff to one set
of names in the kernel, then from that intermediate set to another set
in userland.  However, that's exactly what we have now, with
intermediate names being <major,minor> pairs; I think we can dismiss
other such intermediate-name variants for purposes of this discussion.

> If you want it done in the kernel, you'll either use config syntax,
> or a suitable slight extension of it, to get your constraints built
> into the configuration tables, or you'll invent a new file somewhere
> with a syntax very similar to config and containing data that can get
> out of sync with it, to be read by devfs at mount time or something.

This actually may be a sensible way to go.  I could see the above
turning into, say, two files in the underlying layer: tty00, containing

pci@0/pcib@17,0/isa@/com@2f8,3

correspnoding to

pci0 at mainbus0 bus 0
pcib0 at pci0 dev 17 function 0
isa0 at pcib0
com0 at isa0 port 2f8-2ff irq 3

(whether or not the kernel config has those lines rather than wildcard
variants), and tty01 holding pci@0/pcib@17,0/isa@/com@3f8,4.

> If you want it in userland, it might wind up looking like something I
> remember from Solaris, where there's a /devices directory with
> canonical names like /mainbus/pci@0/ppb@1:0/pci@1/neo@0:1/audio and
> /dev has symlinks into it,

I remember that too.  That actually could be useful; if devfs presented
a /devices-like interface, it could be mounted on (say) /dev/ices and
handle permissions and whiteouts, with naming issues like my example
above handled with the symlinks from the short names in /dev.

About the only thing I don't see that handling is a case where you want
the same device node to exist two different places with different
permissions (maybe one is in /dev and 664 root:wheel, while another is
in /ftpchroot and mode 444).  Using symlink permissions with symperm
mounts helps some, but probably not enough....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B