Skip to content
Xila
Demonstration

WASM driver crate

The drivers_wasm crate provides drivers for WebAssembly targets (wasm32).

Last updatedEdit page

The drivers_wasm crate provides drivers for WebAssembly targets (wasm32).

It offers browser/web runtime integrations such as memory/logging adapters, async execution support, and devices including time, drive, and HTTP client access.

The browser example uses devices::DriveDevice to open the origin-private file xila_drive.img using OPFS and hold a lifetime Web Lock. This main-thread driver keeps a bounded memory cache (16 MiB in the browser example) and commits snapshots asynchronously through sync().await. Synchronous block writes/flushes update the cache; they do not establish OPFS durability.

Only dirty disks are saved. Saves are serialized and atomic, with at most one additional disk-sized snapshot rather than a growing queue. Failures leave unsaved changes available for retry; the caller must handle errors. OPFS quota/eviction and abrupt tab termination can still lose data.

The browser example validates existing MBR/LittleFS data and stops on mount errors instead of reformatting a saved image. See Browser storage for the cache/autosave model and Reset the browser disk for a deliberate reset.

When Xila renders a dirty rectangle to browser Canvas ImageData, its little-endian XRGB8888 buffer must be converted from byte order BGRA-like (B,G,R,X) to the Canvas R,G,B,A order. The SIMD converter now handles trailing complete pixels after 16-byte vector chunks instead of copying their bytes unchanged (Core #403). This matters for rectangles whose pixel count is not divisible by four; it does not change the guest graphics ABI or introduce a new graphics capability.

The browser example mounts /devices/audio/playback only after an explicit Enable audio user gesture. This starts the Web Audio context in accordance with browser autoplay restrictions. The Synth guest can retry audio initialization without requiring an OS restart.

OPFS, FileSystemFileHandle.createWritable, and Web Locks require an appropriate browser and localhost/HTTPS. Only one Xila tab can hold the disk lock. The HTTP device uses Fetch and follows browser restrictions such as CORS; it does not expose raw sockets or provide the Xila network manager.