9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Frank D. Engel, Jr." <fde101@fjrhome.net>
To: 9fans@9fans.net
Subject: Re: [9fans] building blocks speaking 9p
Date: Sat, 29 Jan 2022 07:30:19 -0500	[thread overview]
Message-ID: <6d32f5c3-88fe-74c2-199d-dad448d28511@fjrhome.net> (raw)
In-Reply-To: <0dcffcf1-371b-efd8-b0cf-4236af7f9185@fjrhome.net>

Ok, sorry for the triple-post, but since I can't seem to find that man 
page or usb/ether on my 9front install, I should probably provide my source:

http://man.cat-v.org/plan_9/4/usb


On 1/29/22 7:14 AM, Frank D. Engel, Jr. wrote:
> 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-M06b50380a603d3037a973a37
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  reply	other threads:[~2022-01-29 12:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-29 20:04             ` [9fans] aiju boards Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-01-28 19:32   ` [9fans] building blocks speaking 9p 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. [this message]
2022-01-29 13:24         ` cinap_lenrek
2022-02-15  3:07 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-01-29 20:53 Lyndon Nerenberg (VE7TFX/VE6BBM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d32f5c3-88fe-74c2-199d-dad448d28511@fjrhome.net \
    --to=fde101@fjrhome.net \
    --cc=9fans@9fans.net \
    --subject='Re: [9fans] building blocks speaking 9p' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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