Re: [9fans] building blocks speaking 9p

["Frank D. Engel, Jr." <fde101@fjrhome.net>]

Evidently there are two major standards:

CDC, an official USB standard - specifications here: 
https://www.usb.org/sites/default/files/CDC_EEM10.pdf

RNDIS, a proprietary Microsoft protocol that Linux also provides drivers 
for: https://en.wikipedia.org/wiki/RNDIS


The man page for usb/ether on plan9 indicates that CDC support is 
already there but has not been tested; it may be that a good starting 
point is in place and getting this tested would provide the required 
support on the host side of things?


On 1/29/22 6:56 AM, Frank D. Engel, Jr. wrote:
> 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 <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
>>

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