Platform
HardwareJS
HardwareJS is the JavaScript hardware platform the in-browser Linux kernel runs on. It provides the things hardware normally provides — memory, CPUs, devices — and routes your real USB analyzers, debugger probes, FPGA programmers, and audio gear through to Linux as standard, in-tree, upstream-driven devices.
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.
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 Linux 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.