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 <ba...@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
