Rust SIG Meeting - 2026-05-26

[PLeVasseur]

Hey folks 👋 welcome to our 10th meeting of 2026.

Rust SIG Meeting 2026-05-26

Agenda

1. Solicitation of notetaker

   • Pete LeVasseur

2. Rust Watercooler Chat Topic - Inserting WebAssembly between C++ and Rust for Fun and Profit; Christof Petig - Aptiv

3. Review GitHub repo content and discuss how to enrich (Pete)

   1. Issues
   2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.

4. Office hours - Rust + Automotive questions - come chat! (All)

5. Discuss upcoming events / news related to Rust & Automotive (All)

6. Meeting close

Check-in area

(We had ~14 people around at one point at max, including those listed below)

• @PLeVasseur
• @cpetig
• @bharatGoswami8
• @arnoox
• @arshadm
• @odra
• @mik90
• @MarcosBorgesPhD
• @AntonSchmukel
• @perrymcmanis144
• @adrianaioanei

Housekeeping section, please add

• Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
• GitHub repo: https://github.com/rust-sig/rust-sig
• Eclipse SDV Slack channel: #rust-sig

Tasks

Meeting Minutes

Inserting WebAssembly between C++ and Rust for Fun and Profit; Christof Petig - Aptiv

Slides:

eclipseSDV_RustCpp.pdf

Why interop in this manner, using WebAssembly?

• Combining > 2 languages makes using WebAssembly useful for this
• Useful if stitching together into a single binary
  • Stable ABI bridges incompatibilities
  • wasm sandboxing for untrusted binaries or FuSa

Challenges with WebAssembly for interop

• Threads, zero-copy, generics, object inheritance
• Passing pointers & callbacks
• Bidirectional dependencies

Christian is involved with:

• shipping SAE JA-1020 (now published)
• the Bytedode Alliance, where he serves on the Technical Steering Committee

Background: AUTOSAR Adaptive Platform Stack

• Several years ago an attempt was made to create a Rust stack with all C API & ABI in between, then on to the Adaptive Platform (AP) APIs, then finally up to Rust applications
• Deemed too complicated to make this workable

Solution: Use an ABI which is language-neutral, but not as low-level as the C programming language

• Put Rust stack on top of POSIX51
• Then have WebAssembly Interface Types (WIT) ABI
• Upon which the AUTOSAR Adaptive Platform can be implemented in the relevant language for those applications
  • e.g. Rust applications get to use the Rust implementation of the Adaptive Platform, while C++ applications get to use the C++ implementations of the same
  • Exists document which standardizes the Rust APIs for the Adaptive Platform

Able to fuse together components via integration of WebAssembly Interface Types describing components

• "Like building with Lego bricks"
• Anything on the right side of the diagram could be an output of the overall diagram

Question: Where are the WIT files defined at? Can they be put in the open?

• raised with legal folks at AUTOSAR Consortium about making these public, not immediately said no to
• would allow for a "clean room" description in WIT generated from the AUTOSAR ARXML files

Question: Was it because of ABI issues that you chose not to use Foreign Function Interface (FFI)?

• ABI is not really a question of FFI from viewpoint, seems a separate issue
• Seems like WIT and the generated code and bindings more-or-less amounts to a high-level version of FFI

Other benefits: migrating WebAssembly modules around based on needs

• For example, some can be turned on or off or moved to different modules over
• Record size smallest is several hundred bytes for a .wasm module

Question: How is runtime performance when deployed to something lower-powered, like a microcontroller?

• For their application, they precompile the binary once it's deployed to the central computer
• Memory layout is fixed by WASI, so this is not of concern, even when moving to other archtiectures

Question: AOT Compiler certified? What about runtime?

• Not yet
• There are some forming plans for this

Unify input environment, deploy with flexibility

• support a number of different software components
  • e.g. features from Aptiv, AUTOSAR Classic Platform Software Components (SWCs)
• create portable binary containers
• able to deploy on many diverse target platforms

Parts of what are shown here are "soon"

• Some of it SOP next year
• More of it by SOP 27, 28

WebAssemly introduction

• W3C standard
• compile C programs for the browser
  • multi-threading wa sa weak point from the start
• A well-defined virtual CPU target with dedicated linear memory which can be translated to real CPUs in a single pass
  • Was important for usage in the browser
• Emscripten started to compiling to asm.js, then wasm (kind of the first generation, what we talk about today is mostly 3rd or 4th generation)
  • threads are emulated with web workers and JavaScript glue
  • Rust uses wasm-bindgen for this target

Timeline

• 2015 WebAssembly: Run C in the browser more efficiently than asm.js
  • of course, got Doom running
• 2019 WASI 0.1: Run wasm on the server, still very posix-like
• 2025 WASI 0.2: More modular, less POSIXy, "how to pass a string?"
• 2026 WASI 0.3: Async planned
  • Announcement was made
  • Still need to follow-up
  • Strange race condition when porting to the browser that could lead to locking up of the browser

Features of the Component Model:

• Sandboxing, language and OS agnostic interfaces
• Formerly called Interface Types
• Roughly 2x as fast as using JavaScript
• More and more realistic this year to run WebAssembly in the browser

Question: Does using wasm restrict any of Rust functionality or functions?

• Yes and no
• tokio-rs not yet fully supported; may merge this summer
• waiting on an LLVM patch that's a bit stalled
• multi-tasking, single-threaded would then be possible
  • e.g. cannot spawn new threads, only tasks

Component Model

• A different ecosystem than emscript
• A new binary format
  • multiple modules (binaries)
• (add more from screenshot)

WebAssembly Interface Types (WIT)

• (add more from screenshot)
• single threaded execution environment, but things like pthread will work

WebAssembly System Interface (WASI) intro

• WASI is like POSIX interface to the underlying platform/kernel
• e.g. random, clocks, sockets, filesystem
• standardized set of WIT files for interacting across the WASI

Question: For real-time systems, does using wasi introduce any latency? Are there any known issues with Wasm runtimes in your experience?

• with Ahead-Of-Time (AOT) compilation there's no large performance penalty
  • ~5% performance penalty
• with Just-In-Time (JIT) usage, there may be performance differences due to differences in operation layout and cache
• assume for this talk that we're always talking about

Question: Do "sockets" include unix sockets (uds, etc)?

• TCP/UDP, not Unix Domain Sockets (UDS) since that would only work on a single operating system
• Pipes sort of work with WASI 0.3
  • Can use a stream, give reading end of stream to a different component
  • Get pretty close to what is done with UDS

Question: To get hardware acceleration, your host must offer up this capability?

• Correct, there are examples of this today

Question: How do all of the WebAssembly items get put together?

• Guest environment, host environment typical
• But in the case of for example microcontrollers you would tend to package all .wasm modules together into a single binary

Canonical ABI

• Arguments on stack vs in-memory threshold
• Mechanism to allocate and free from linear memory
• WASI 0.3: Conventions for async waiting & callback

Component Model call in detail

1. Host calls cabi_realloc to allocate in linear memory
2. Host passes address and length to guest function
3. Guest puts string somewhere (malloc?); stores address and length in static memory, returns address
4. Host process string and calls cabi_post_F to allow for resource cleanup

Question: To what level will you safety-certify?

• Going for somewhere between ASIL B to ASIL D
• Zero-copy is important for higher levels of safety criticality, especially for Automated Driving/ADAS applications

Question: Everything allocated during call will be freed, right?

• Host uses cabi_realloc which means that ownership is passed
• Theoretically the guest could choose to store the loaded memory as long as possible

Stream in detail (by Luke Wagner)

• Skipped for today, watch the talk if interested
• Link to some representative talks:
  • A stream on the future in the Component Model - Wasm I/O 2024
  • Threading the needle with concurrency and parallelism in the Component Model - Wasm I/O 2025
  • Towards a Component Model 1.0 - Wasm I/O 2026

Symmetric ABI

• Inspired by guest to host calls
• Callee exports the interface expected by the caller, no host intermediate
• Argument Strings are borrowed, results are moved
  • No way to take a C++ String and move it to the Rust side which causes this restriction
  • Limitation of C++ standard library, which causes reallocation
• More complex resource and stream changes
• Requires a redefinition of the ABI, but no change required to the WIT

Avoiding allocations -- different approaches

• caller provided buffers
• lazy lowering
• shared memory (publisher subscriber)
  • Not yet qualified, but this is the intended route
  • Avoids all the need for allocations

WebAssembly in Automotive

• AUTOSAR Adaptive uses WIT/Symmetric ABI
• The dream of portable binaries (OS + arch agnostic)
• VSS/uProtocol WASI equivalent needed see e.g. vspec2wit (ETAS, COVESA 2023)

Outlook for the future

• Cooperative threads are coming
• Zero copy, zero allocation, publisher subscriber (upstream coordination since January with LLVM)
• Shared everything threads (farther out goal)

Personal (@cpetig's) TODO

• Merge C symmetric async upstream
• Document symmetric mode in upstream
• Standardize shared memory
• Undust C++ AUTOSAR adaptive example

Resources

• https://bytecodealliance.org/
• https://github.com/cpetig/wit-bindgen
• https://wasmcon24.sched.com/event/1qvIG/component-model-in-software-defined-vehicles-christof-petig-aptiv

Demo today

• Not using WebAssembly
• Not sandboxed

Question: Uses AOT compilation to strip out WebAssembly?

• Not in the demo shown today, but has tried this and it works
• Longer story to bring to microcontroller
• Have compiled one component to .wasm, then stripped it down, optimized it
• .wasm to C transpiler to create workable binary, then would be sandboxed

Question: Where would we use Symmetric ABI?

• Would use this one if compiling to native
• Compiling to something for the web, or browser use the canonical WebAssembly ABI
• Independent of code; there's a different code generator

Recent events / things coming up for Rust

RustWeek 2026

• https://2026.rustweek.org/

Requested topics

xx

Material

Any material to read before the meeting should be included here.

[bharatGoswami8]

@bharatGoswami8

[arnoox]

@arnoox

[arshadm]

@arshadm

[arshadm]

@arshadm

[odra]

@odra

[mik90]

@mik90

[MarcosBorgesPhD]

@MarcosBorgesPhD (waiting approval to join the group)

[PLeVasseur]

Hey @MarcosBorgesPhD -- does that mean you applied here on this page?

https://eclipsesdv.org/rust-sig/

I recall in the past we had an issue where notifications somehow broke for this.
If you can confirm you applied on that page, I'll check in with Eclipse Foundation staff on what the issue might be.

[MarcosBorgesPhD]

Hey @PLeVasseur, yes, I created an Eclipse account and submitted my application on 13 May using the page you mentioned. Thank you!

[AntonSchmukel]

@AntonSchmukel

[charcoalfrostmetallic]

@perrymcmanis144

[adrianaioanei]

@adrianaioanei