HardwareJS

What it is

In a brintOS session, the browser is the hypervisor and WebAssembly is the instruction set — but the kernel still needs hardware to run on. HardwareJS is that hardware, implemented in JavaScript. It backs the kernel's RAM with a shared SharedArrayBuffer, brings up a fixed pool of Worker threads for the kernel to use as CPUs — each a real OS thread that enters kernel code against the shared memory, so the kernel's own SMP locking is honored — routes system calls between userspace and the kernel, and exposes every physical peripheral on your machine to Linux as a device the kernel already knows how to drive.

One verified release across launch environments

Each hosted machine pins its exact HardwareJS version in Settings → Machine spec. Local launches infer it from the versioned kernel filename or an explicit approved override. brintOS serves that release's hardwarejs.js, hardwarejs.html, and release.json as public static files under /hardwarejs/<version>/. Repository JavaScript does not become host code. Current launch approval is checked separately, so an immutable download cannot override revocation.

Browser machines keep their sandboxed iframe and separate machine origin. Local Node launches and cloud machines use the same verified Node runtime. See the runtime selection guide for image preparation, download verification, and launch requirements.

How real hardware reaches the kernel

HardwareJS exposes each class of physical device through a standard Linux interface: virtio for storage, network, console, audio, and the host filesystem; an emulated xHCI host controller for USB. The kernel's existing in-tree drivers handle all of them — the same drivers a real KVM guest or a bare-metal Linux box would use. Userspace sees /dev/ttyACM*, /dev/ttyUSB*, /dev/snd/*, /dev/input/*, /dev/sd*, and /dev/bus/usb/ exactly as it would on bare metal. Nothing in userspace knows or cares that it's running in a browser tab.

On the browser side, each device backend wraps the corresponding Web platform API: navigator.usb for USB devices, navigator.serial for direct serial adapters, the WebMIDI API for MIDI controllers, WebAudio and WebHID for their respective device classes, and the File System Access API for mass storage. When a Linux driver issues a request, HardwareJS translates it to the corresponding browser call, places the response into the device's queue in shared memory, and signals the kernel.

Devices that work today

• USB-CDC serial adapters, USB-to-UART bridges, debugger probes (STLink, J-Link, Black Magic, CMSIS-DAP).
• Logic analysers (Saleae, DSLogic), oscilloscopes that speak USB-TMC.
• FPGA programmers (FTDI MPSSE, ULX3S, Olimex).
• HID keyboards, mice, and game controllers; MIDI keyboards and controllers.
• Mass-storage class drives, mounted into the running machine.

Why this approach

Most hardware drivers in mainline Linux assume privileged access to PCI, MMIO, and physical interrupts — none of which a WebAssembly process can offer. The choice was to either rewrite a driver per device class (fragile, never-ending, always one upstream change behind), or to present each device through an interface Linux already drives natively. We chose the latter. Exposing virtio and emulated xHCI as the transport means brintOS inherits decades of upstream Linux work for free: every USB device with a working Linux driver is a device that works in your browser tab, with no porting and no forks.

How it fits with the rest of the stack

HardwareJS is one of three platform pieces. The kernel — Linux 6.12 LTS compiled to WebAssembly — runs on top of it. Userspace programs are built by the brintOS toolchain — our LLVM/clang compiler with a choice of musl or glibc — into wasm executables that the kernel execves; HardwareJS instantiates each as a wasm module that the kernel schedules onto its pool of CPU Workers. For the full picture of how a browser tab becomes a Linux machine, see Computer in the Browser.

If you build hardware tooling and want it to "just work" on brintOS, get in touch — we maintain a private compatibility list and we're happy to add devices.