Drivers in WASI

[SamuraiCrow]

I've been looking over various proposals for drivers in WASI and I think a consesus needs to be raised up on the subject. So far, every abstract type of driver whether it be SPI, USB Serial or any other driver interface has been treated like a separate proposal. I'd like to propose a different framework to add drivers in a more abstract way.

Volitile Memory-Mapping

Every memory-mapped driver has a block of addresses that contains control registers for a particular device. If there were a way to access these from the WASI sandbox, it would be possible to write drivers for MMIO devices within the WebAssembly ecosystem. Of course the sandbox environment itself should block access to hardware-banging except via driver support, but if there were a way to wrap or even rewrite drivers to be instruction-set agnostic, I think that would be a boon to the electronics industry as a whole.

Ways To Make It Happen

There are several ways to make this happen but since this is a discussion rather than a formal proposal, I'd like to hear your thoughts on the subject. Also, if this gets elevated to the main WebAssembly working group, it will probably need a new protocol external to WASI. It will still affect WASI though so I thought I would bring it up here first. Feel free to share!

[devsnek]

this sounds like it could be an interesting use case for multi-memory

[SamuraiCrow]

If the multi-memory proposal has a way to add a flag indicating volitile memory blocks, then yes!

[sunfishcode]

I have no experience in the driver space, so I'm curious how this might work.

If we had a way to do a volatile memory mapping in wasm linear memory, I assume there'd need to be some form of address translation, so that a store to linear memory at some index X can be translated to a store to some specific physical (virtual?) address Y. So my first question is, how might this mapping be configured? Who (wasm module and host/engine) knows what (linear-memory address and physical (virtual?) address) when (wasm producer time, startup time, or runtime)?

My second question is, is memory mapping essential? If we had an API containing functions for performing reads and writes to I/O, instead of using loads and stores, would would be the impact? Some of the pros would be:

• it'd open up drivers to more source languages, because very few source languages have a native concept of volatile, but every relevant source language can call imported functions.
• It'd open up drivers to virtualization; you could run a driver on emulated hardware just by having a software implementation of the functions.

What would the cons be?

[SamuraiCrow]

There are a few more pro's as well:

• The role of the host operating system will be diminished because native drivers won't be needed ever again. Next-gen operating systems can freely use these drivers as their own.

• Bytecode drivers can optinally use "force inline" of any trivial accessor methods while preserving the driver API for better performance. (As long as the hardware configuration remains unchanged. If it is changed, the affected software will need to rebuild from bytecode to propegate the dependencies.)

• Clears the way for FPGAs and CPLDs to provide stable hardware APIs to avoid translation overhead due to bytecode compilation.

This leads to the ever-present cons:

• Bytecode translation time may increase considerably until legacy "card slot boxes" give way to integrated "stacked chiplet" SBC designs taking over.

• Disruptive technologies like this one upset the "apple cart" for existing operating system creators.

[SamuraiCrow]

To answer your first question, the address translation could be implemented in the bytecode compilation on the destination platform. Oftentimes the base address of the card-slot determines the final address of the registers contained in the i/o memory mapping. Each card-slot has its own window in the memory map.

The advantage of single-board computers is that they have no card-slots so that cores can be mapped into memory at a permanent address without ever needing to move to another slot. As chiplet stacking takes over the role of card slots, all computers will become SBCs and what card-slots used to be will become ports in a more speciallized architecture.

[ttraenkler]

• Bytecode drivers can optinally use "force inline" of any trivial accessor methods while preserving the driver API for better performance. (As long as the hardware configuration remains unchanged. If it is changed, the affected software will need to rebuild from bytecode to propegate the dependencies.)

This seems to be another use case for the forced inlining of calls of imported functions as suggested here, enabling performance sensitive, close to the metal functions to be isolated in a separate module.

EDIT: Updated link

[SamuraiCrow]

Since this seems to be somewhat inline to what some other people are thinking, I'd better raise the possibility of some "stretch goals" for drivers that extend beyond mere memory-mapped i/o. Adding support for the following types of devices will require careful thought.

DMA Control

Devices that have internal buffers often times use direct memory access (DMA) to transfer contents into and out of the device. This is normally beyond the control of software because the device literally takes over the memory bus independently of the CPU.

IOMMU

Devices that perform their own compute capabilities (mostly graphics cards) oftentimes have a proprietary i/o memory management unit (IOMMU) which aids in address translation and extends the buffer addressing range of what might already be a heavily populated set of chiplets. These are operated on by drivers exclusively since they are usually proprietary and integrated into the device.

[SamuraiCrow]

As a follow up note: developer X512 on the Haiku operating system posts on the Haiku bugtracker detailing how he was able to leverage open source Gallium3D and Mesa to run a Vulkan capable driver on a user-mode libDRM implementation on Haiku. (For anyone unfamiliar with Haiku, its the open-source spinoff of BeOS used on the BeBox multi-processor computer back in the 90's.)

See https://dev.haiku-os.org/ticket/9919#comment:8 and the following comment.