9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] building blocks speaking 9p
@ 2022-01-29 20:53 Lyndon Nerenberg (VE7TFX/VE6BBM)
  0 siblings, 0 replies; 33+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-01-29 20:53 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 33+ messages in thread
* [9fans] building blocks speaking 9p
@ 2022-01-27 22:57 Bakul Shah
  2022-01-28  2:55 ` Thaddeus Woskowiak
                   ` (5 more replies)
  0 siblings, 6 replies; 33+ messages in thread
From: Bakul Shah @ 2022-01-27 22:57 UTC (permalink / raw)
  To: 9fans

The idea:
- make it very easy to create hardware gadgets by
  providing a firmware/hardware building block that
  talks 9p on the host interface side & interfaces
  with device specific hardware.

- use a "universal" 9p driver on the host side that
  allows access to any such 9p device even from a shell.

- provide a standard way to find out device capabilities.

- together they provide a plug-and-play setup.

Example: connect an LED and a current sensor to this
9p device, other necessary hardware, add a few config
bits and plug this device kn]]into a host. Now you should
be able to turn on/off the light or sense its state.

Similarly you should be able to control a stepper motor
servo, cameras, microphones, other actuators, sensors,
IO etc. Eventually you should be able to snap together
enough of these components to build larger assemblies
such as a 3D printer.

Another example: a "hub" to multiplex such downstream
devices and make them available to a host.

This will probably have to ride on USB first. A verilog
implementation would be useful in an FPGA!

Would this be a useful component? If such a thing were
available, what would you want to build with it?

Do you think 9p is the right protocol for this?

Ideally
- connect anything to anything
- authenticated connections
- drive the device through a shell script
- no new low level drivers
- self-identifying devices with help and command syntax
- signicantly eases the task of creating new h/w devices.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M35165d4278d95e41fd95b8f7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2022-02-15  3:08 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-29 20:53 [9fans] building blocks speaking 9p Lyndon Nerenberg (VE7TFX/VE6BBM)
  -- 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)

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).