[ Nate and Brett L. have been discussing Brett's prtconf utility ]
Perhaps some of this can be rolled into the dynamic configuration work
(which will require much more public locator support).  The locator data
can't be taking up that much space, and I don't see any reason for it to
be wired down.  I'd much rather see this in the tree in a more advanced
form than in its current form.  It's also kind of orthogonal to unifying
the device namespace.

Olaf said:
> Like the device names, it would be logical to have device nodes for all
> of this. It is a bit silly (to say the least) that one has to do a call
> to socket(2) and use funny network protocol types, when for a disk one
> merely has to open("/dev/sd0c", ...). Having it in a directory tree
> structure would be the logical thing too, I think.

The current way of accessing some devices differently than others may be
a bit silly, but that's also kind of tangential.  In some way, it would
be nice to export this information, perhaps via sysctl--perhaps via kernfs.
I don't want to use this kind of information to address things in /dev
(or /devices ala Solaris: /devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@1,0:a,raw).

While a utility to locate the ancestry of my current disk0 or tape0
would be nice, and opening/controlling devices in a more orthogonal
fashion would be more consistent, neither issue really addresses a
more unified device namespace or the utility (or lack thereof) in
using the tty system as a prototype or proof-of-concept or starting
point for this.

I think that this will be more interesting as we get more and more
interesting ways of attaching similar devices.  TTY devices can
currently come from where?  USB, PCMCIA, ISA, PCI, VME, NuBUS,
main I/O bus (obio/IOASIC/whatever), etc.  I'm sure there will be
more in the future.

-allen