Re: (Semi-random) thoughts on device tree structure and devfs

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

> That doesn't work. Suppose I plug disk B into slot 2, then disk A into
> slot 1, but tomorrow I plug disk A in first?  Or, suppose when I reset
> the machine the vagaries of power distribution or who knows what cause
> either one disk or the other to spin up and come ready first on
> different days?

In my devfs, devices are enumerated in the local connection.

        /dev/mainbus0/.../piixide0/ata0/wd0
        /dev/mainbus0/.../piixide0/ata1/wd0
        /dev/mainbus0/.../piixide1/ata0/wd0
        /dev/mainbus0/.../piixide1/ata1/wd0

> Also, sometimes you can't tell which is slot 1 and
> which is slot 2...

Use IDs.

> I think an explicit graph (rather than trees with symlinks) is a
> better approach in the long term.

See the original post.  I showed the reversed pseudobus, which I've found
very powerful.  More examples:

        /dev/mainbus0/.../screen0/vt100emul0
        /dev/mainbus0/.../screen0/wsmuxout0
        /dev/mainbus0/.../kbd0/wsmuxin0
        /dev/mainbus0/.../mouse0/wsmuxin0
        /dev/pseudobus0/wsmux0/wsmuxout0 -> /dev/mainbus0/.../screen0/wsmuxout0
        /dev/pseudobus0/wsmux0/wsmuxin0 -> /dev/mainbus0/.../kbd0/wsmuxin0
        /dev/pseudobus0/wsmux0/wsmuxin1 -> /dev/mainbus0/.../mouse0/wsmuxin0

Where screen0 has two children, vt100emul0 and wsmuxout0.  wsmuxout0 *joins*
wsmux0.  kbd0's child wsmuxin0 joins wsmux0 too.  When kbd0 receives a
character, it delivers it to wsmuxin0, which in turn delivers it to wsmux0,
which in turn delivers it to wsmuxout0, then finally screen0.  screen0 sends
the received character to its child vt100emul0.

Now how multi-head support looks is pretty much straightforward.

bridge(4) + tap(4) + some ether(4) would look exactly same manner.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635