Re: [9fans] building blocks speaking 9p

["Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>]

A few thoughts after chewing on this for a day ...

I think the major architecture components break down like this:

1) a simple protocol wrapper to enable streaming of 9p over arbitrary
   transports (e.g. USB, i2c, spi, rs485).

2) an addressing scheme that plugs into dial() and ndb.

3) authentication proxies.

4) device libraries.

I think (4) is out of scope for the current discussion, so I won't
talk about it further.

(1) is the key to the whole thing.  We need a consistent way to
expose these 9p streams in the kernel in a mount-friendly way.  I
think the netif/ether kernel framework provides a good starting
point, where netif hides (or at least abstracts) the device-specific
quirks of the underlying physical medium (e.g. X-Base-T, wifi).

In the current case, the netif replacement layer would hide the
transport-specific warts of the physical tranport medium (e.g.  USB,
spi, serial uart).  Where it gets interesting is how we address the
individual components.  E.g. at the "device" layer we need to address
specific end-points, such as USB device endpoints, or an i2c chip
addresses (for both the i2c driver chip, and the device on its i2c
bus we want to talk to).  Then above that we should have a way to
address the generic 9p stream.  Or maybe not -- implementation
experience will show if this is required.  This naturally leads
into (2).

(3) gets tricky.  Devices not directly connected to a TCP transport
can't speak with the auth service.  Two ideas come to mind.  The
upstream "gateway" host could export a namespace that provides just
enough to allow the device to chat with the auth service; I haven't
thought about how this would work.  Another option would be to have
the "gateway" provide an auth server relay service that would be
part of the 9p streaming encapsulation layer -- basically a 9p
bent-pipe proxy to the auth service, listening at a well known
"address" within the encapsulation layer.


I've been thinking about doing something like this for ages,
specifically, to allow me to control a stack of radio transceivers
via a collection of controllers wired up to a multidrop RS485 bus.
So last night I bit the bullet and ordered up a stack of RS485
interfaces of various shapes and flavours for my collection of
Pies, Arduinos, and PCs, with a couple of USB adapters thrown in
for good measure :-)  When they get here I'll get to work on
implementing the RS485 bus layer, and see where it all goes
from there.

--lyndon

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T18287f976e8461f3-M89dba67665ed6ae12c21e8b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription