9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] building blocks speaking 9p
Date: Sat, 29 Jan 2022 12:53:29 -0800	[thread overview]
Message-ID: <4409edc5f8c744c8@orthanc.ca> (raw)

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

             reply	other threads:[~2022-01-29 20:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-29 20:53 Lyndon Nerenberg (VE7TFX/VE6BBM) [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-01-27 22:57 Bakul Shah
2022-01-28  2:55 ` Thaddeus Woskowiak
2022-01-28  3:31 ` Lucio De Re
2022-01-28  5:16   ` Bakul Shah
2022-01-28 10:16     ` Lucio De Re
2022-01-28 19:01       ` Charles Forsyth
2022-01-28 21:26         ` Bakul Shah
2022-01-28 21:37           ` Eli Cohen
2022-01-28 20:54       ` Tony Mendoza
2022-01-28 20:59       ` Tony Mendoza
2022-01-28 21:03         ` ori
2022-01-28 21:07           ` Tony Mendoza
2022-01-28 21:06         ` Eli Cohen
2022-01-28 21:16           ` Tony Mendoza
2022-01-28 21:27             ` Eli Cohen
2022-01-28 21:33               ` david
2022-01-28 21:46                 ` Tony Mendoza
2022-01-28 22:23                   ` David Boddie
2022-01-29  1:04                 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-01-29  2:08                   ` David Boddie
2022-01-29  3:36                     ` Tony Mendoza
2022-01-29 18:03                     ` David Boddie
2022-01-29  2:32           ` Thaddeus Woskowiak
2022-01-28 19:32   ` Kent R. Spillner
2022-01-28  4:54 ` ori
2022-01-28 20:55 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-01-29  9:16 ` Skip Tavakkolian
2022-01-29 11:56   ` Frank D. Engel, Jr.
2022-01-29 12:14     ` Frank D. Engel, Jr.
2022-01-29 12:30       ` Frank D. Engel, Jr.
2022-01-29 13:24         ` cinap_lenrek
2022-02-15  3:07 ` Lyndon Nerenberg (VE7TFX/VE6BBM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4409edc5f8c744c8@orthanc.ca \
    --to=lyndon@orthanc.ca \
    --cc=9fans@9fans.net \
    --subject='Re: [9fans] building blocks speaking 9p' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).