WASI Serial api

[lachlansneff]

Recently, I've been casually involved in the hardware scene and I've realized that programming and interfacing with hardware can be annoying platform-independent. Often software will work, but it's quite complicated to get all the dependencies it requires in exactly the right place. I've noticed some niches start to move towards packaging software as wasm modules that can run on any platform with a compliant wasi runtime (see YoWASP), but this hasn't included the programmers and debuggers themselves. To fully fulfill that role, WASI would need a USB api (akin to WebUSB), but a low-hanging fruit, which would still go a very long way, is a serial api for WASI.

I went ahead and wrote a preliminary witx module (see here) and also implemented a (pretty rough) wasmtime crate for it (see here).

My goal here is to open the conversation about what interfacing with external hardware through WASI could look like. The API I've come up with here does not follow the capability-based security that WASI is based on, so it's obviously not finished.

Applications:

• Programming and debugging microcontrollers (e.g. arduinos, etc) and FPGAs
• Interfacing with MIDI devices(?)
• lots more stuff

[lachlansneff]

If there's no interest in a serial api, I'll close this issue.

[programmerjake]

I guess that there are more interested people, just that most of them (like me) are fine letting someone else do the initial work and only saying something if it looked broken somehow.

[lachlansneff]

I already implemented it, and linked to the implementation in the issue above. But it needs discussion of how security can work in this context before a PR can be made.

[programmerjake]

I'd consider security and related API design discussions to be partially part of "initial work"...

In any case, there is at least 1 other person interested in this (me), so it might be worth reopening, even if it may take a long time due to low interest.

[sunfishcode]

I don't have an immediate use case for this myself, but it is an interesting feature.

This highlights an area where WASI's infrastructure needs to provide better support: we need better mechanisms for passing new capabilities into programs.

On the proposal itself, how important are 7-bit, 6-bit, and 5-bit data streams these days? If there aren't many devices that need these, it might be nice to avoid including these so that we can more easily abstract over these streams and other kinds of datastreams (files, sockets, etc.) which will likely all be 8-bit?

[programmerjake]

there's also 9-bit and bigger serial protocols that make really messy APIs.

[beriberikix]

I'm torn while I suggest this but it probably makes sense to use Web Serial API is the starting point of a Serial API. In lieu of champions who can express the nuanced differences between RS232 on windows vs tty (for example,) it is reasonable to adopt the constraints spec'd by the W3C folks as a starting point. And it is also reasonable to assume that some users will be using WASI in some browsers that support Web Serial if it ever does become a ratified standard.

[zwhitchcox]

This would be useful for creating in-browser drivers for USB devices with lower latency than usbip for example.

Especially for drivers you only want to use one time or have frequent changes.

For example, to flash a beagle bone black with the S2 button, it exposes an RNDIS interface, which expects a pbx server (tftp server with the bootloader/spl) which then converts it to a ums.

Rather than download all these drivers, you could just flash from an electron process running the WASI code.

The same is true for many IoT devices, like the Jetson line, and many compute modules/carrier boards.

+1 for serial interface!

[lukedukeus]

Still would love to see this / use it.

[sascha1337]

Wen

…

On Sat, 19 Nov 2022 at 11.15 lukedukeus ***@***.***> wrote: Still would love to see this / use it. — Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6MWVNKTFOQINNQTEBER2DWJBA37ANCNFSM4TOE33NQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sunfishcode]

We've always known that we wanted to build WASI on top of WebAssembly standards rather than having WASI invent everything it needs for itself. WASI needs an IDL, and there is now one being developed toward becoming a WebAssembly standard: wit. It will provide many things that WASI needs, such as support for non-C-like languages, support for capability-based security, proper support for types like string, list, variant, and so on. So it makes sense that WASI should aim to be built on wit rather than building up a whole separate IDL and having to solve all the same problems in a parallel system.

Wit has turned out to take longer than initially expected to develop, but it is progressing. I recommend this talk for anyone interested in the path to how we got to where we are now, and the road ahead.

If anyone is interested in prototyping a WASI serial API with the wit IDL, the wasi sockets proposal is an example of how to work with wit. The wit tooling is still in development, but it is possible to work on this in parallel.

[RaulRG]

My company would be quite interested in serial support for webassembly (RS232, USB, ...). We have got some software that could be ported to webassembly only if we could access serial ports as we communicate with different devices using it. I think that is something quite interesting / important for WASI to be general-purpose.

[rccarlson]

If you're still looking for interest in this, I have a project I would like to distribute as WebAssembly, but it requires access to a user's peripheral device via serial connection.

[FrankReh]

Seems like the pieces are in place for someone to give this a try.

A WIT could be created that defined a resource representing a serial port. A Rust embedder could be written with the WasmTime library and creates like serialport, mio-serial, or tokio-serial.

The Component guest could be written in any language that can be compiled to a wasm32-wasi2p target.

I don't understand the questions around security. The embedder CLI, like a fork of WasmTime CLI, would require the user name the ports they want to give their tool access to.