From: "Frank D. Engel, Jr." <firstname.lastname@example.org> To: email@example.com Subject: Re: [9fans] building blocks speaking 9p Date: Sat, 29 Jan 2022 07:14:43 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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 <firstname.lastname@example.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
next prev parent reply other threads:[~2022-01-29 12:15 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. [this message] 2022-01-29 12:30 ` Frank D. Engel, Jr. 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).