Apparently Linux includes drivers for tunneling IP over a USB connection
(possibly to support mobile phones? not sure...)
Making host drivers compatible with these (if not already available) to
share an IP stack and creating the equivalent device-side support for
the "blocks" would allow 9P to be tunneled not only from these devices
but also from other existing solutions in a wider variety of ways, also
making it easier to connect those devices to Linux as there are ways to
talk 9P from there.
That may open up some additional flexibility?
On 1/29/22 4:16 AM, Skip Tavakkolian wrote:
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
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mf859fd621824fda00d5f5c43
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
