> I wouldn't entirely mind having a /dev/devtree such that I could say
> 	mount -u /dev/devtree/pci0/aic0/target0/lun0/a /
> but that may be a bit excessive.

Somewhere in the archives should be a message from me proposing
something similar, though the details would be different.  Some of the
path elements in your example are configuration tree node names and
some are locators, which complicates things greatly one way or another
(either the /dev/devtree code has to know which is which and when, or
the autoconfig machinery has to be changed).  Consider the following
dmesg output excerpts:

mainbus0 (root): Sun 4/65
sbus0 at mainbus0 ioaddr 0xf8000000: clock = 25 MHz
esp0 at sbus0 slot 0 offset 0x800000 level 3: ESP100, 25MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <SEAGATE, ST12400N, 8650> SCSI2 0/direct fixed
sd0: 2048MB, 2621 cyl, 19 head, 84 sec, 512 bytes/sect x 4194685 sectors

Now, you could call this /mainbus0/sbus0/esp0/scsibus0/sd0 without
ambiguity, but that doesn't really buy you much over calling it just
plain sd0.  Or you could call it

.../ioaddr=0xf8000000:sbus/slot=0,offset=0x800000:esp/:scsibus/targ=0,lun=0:sd

where the parts before the colons are the locators from autoconfig.
Strictly, of course, the "sbus", "esp", parts are redundant, but it
seems to me they'd be useful as a consistency check, and also to allow
userland to glob, say, ".../*:sbus/*:esp/:scsibus/targ=2,lun=0:*" and
inspect the result to see what, if anything, is there, or perhaps to
find all scsi devices (for sysinst?) "find ... -name :scsibus -print |
while read path; do ...$path/*...; done".  It would be trivial, as I
understand it, to do the directory structure; it would basically just
mirror the tree built by autoconfig.  The leaf nodes would require that
the drivers be able to inform devfs (or whatever you call it) of the
appropriate dev_t values for the devices they find.

And yeah, targ=4,lun=0:sd may happen to be sd2 one boot and sd0 the
next.  As long as the .../targ=4,lun=0:sd node has the correct major
and minor numbers, this doesn't matter.  (Just be careful to symlink to
it, not just mknod a copy of it!)

This would be not entirely unlike Solaris /devices, but unlike that,
what I'm envisioning would be exported directly by the kernel rather
than being constructed separately.  It also has no place to put drivers
that don't correspond to hardware found by autoconfig, most notably
pseudo-devices.  Anyone for .../pseudo/pty, .../pseudo/ccd?

>> Perhaps you want a scsifs that you can mount -o union on /dev, [...]

>> Is it worth it?  To me, it is not worth the effort it would take to
>> implement it.  If you feel differently, go to it!  I think such a
>> scsifs would be a Pretty Cool Hack, even if I probably wouldn't use
>> it myself.

> In general, I'd like a lot more run-time control over the device
> tree, and a lot more ways to probe at it.

How does the above devfs sound?  It's general enough that I might
manage to invest a little time in implementing it; if it'd be good
enough for your purposes it could be a win for both of us.

This does not address dynamic reprobing.  That's a completely separate
can of worms, independent of how the devices are presented.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B