Re: [9fans] building blocks speaking 9p

[Skip Tavakkolian <skip.tavakkolian@gmail.com>]

I've been working on something along those lines for IoT management
and networking. Here's my laundry list of architectural and
implementation pieces:

1. authentication: (a) tie devices to owner/user (b) authenticate
users against third parties (via OIDC/SAML2, etc), (c) let the
authenticated user provide the credentials to authenticate and use
their devices via a namespace that follows an established convention
(e.g. /joe/iot/0/secret).
2. device and capability discovery is a bootstrapping process,
starting with a namespace that describes the availability of devices
and features (analogous to '#c/drivers')
3. namespace to discover how to present the data from a particular
source (e.g. a steam gauge widget would need to understand the
namespace exported by a pressure sensor)
4. 9p libraries including fan-in, fan-out capability (i.e. mount,
9pserve) for FreeRTOS, Mbed OS,  ThreadX, Zephyr
5. libraries to localize user↔device 9p traffic, while keeping
authentication centralized (e.g. how @tailscale works)

Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and
actuators, until standards and conventions are established.

For hardware, targeting things like SAMD21 boards seem more
appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic
nRF52840 boards are below $10 and include the hardware to establish
root-of-trust.


On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah <bakul@iitbombay.org> wrote:
> 
> 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-M79ef31466316e414d50336d2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription