Skip to content

Native Linux VMs

Read these articles before this tracking issue:

This tracking issue covers the current state of the native Linux VMs.

What is native Linux VMs?

This is virtual machines running a Linux distribution and being interpreted as native on the Redox terminal and desktop environment.

Implementation

The virtual machine will contain a rootfs for drivers or programs that communicate with Redox using VirtIO drivers.

Why rootfs?

rootfs is the most simple Linux image for customization, also use less space and resources.

Why VirtIO?

VirtIO allow easy paravirtualization to remove the device emulation cost on the guest VM, the Redox system interfaces and devices are interpreted as native Linux interfaces or devices.

Variants

There will be three variants: driver, filesystem and app

Why? because it's optimized to use less space and resources, a "driver VM" only need to care about drivers and a "app VM" only need to care about programs.

  • driver - Only contain driver kernel modules
  • filesystem - Only contain storage driver modules and filesystems
  • app - Install programs

Why separate the drivers from filesystems?

To avoid data corruption due to driver bugs.

Driver VM

The driver VM will be loaded on boot and expose the hardware devices to Redox.

Filesystem VM

The filesystem VM will be loaded on boot and offer the Linux filesystems to Redox.

App VM

Terminal

A terminal tool will read and run the programs of the app VM, see some examples:

  • Show all programs of the app VM
revm ls /usr/bin
  • Install the "btop" program on the app VM
revm apt install btop

GUI

The Redox desktop environment variable will import the program XDG shortcuts of the app VM, the user should also be able to access the app VM files from the file manager.

Each app VM program should be launched with the window manager decoration.

Configuration

The rootfs image must be customized from a script or program and be silently loaded by QEMU.

TODO: find a way to do this

rootfs

Questions:

  • Should we use the Linux distribution rootfs and customize?
  • Should we build our own customized rootfs from source?

Redox bridge

The bridge will be a daemon that exchange data from Linux interfaces to Redox interfaces, it runs on each Linux VM and in Redox.

It needs to be loaded on boot.

Implementation methods

This section explains how the Redox bridge program can be implemented.

  • Kernel module
- Pros: More performance, context switches aren't needed
- Cons: The code needs to be ported for each new Linux version
  • User-space daemon
- Pros: Don't need to be updated if the Linux version changes
- Cons: Less performance, context switches are needed

Schemes

Each used Linux component will offer a scheme to Redox.

  • The display.* scheme will be used to offer Linux DRM resources
  • Each Linux filesystem will have its own scheme, EXT4 and Btrfs are the priority

Tooling

This section cover tools that can be used.

Recipe Script Draft

  • Create a recipe with the [build] section and script data type
  • Create a dynamically-sized QEMU disk image of 5GB
  • Create a Btrfs filesystem on the QEMU hard disk image
  • Insert a command to download the "rootfs tarball musl base" image from Void Linux on the script data type
  • Extract the rootfs tarball
  • Copy the Redox bridge daemon executable to the rootfs folder and enable it on runit
  • Copy the rootfs files to the QEMU hard disk image

TODOs

  • Port QEMU
  • Configure the Linux distribution rootfs recipe
  • Add the QEMU command options for the driver VM
  • Add the QEMU command options for the filesystem VM
  • Add the QEMU command options for the app VM
  • Create the revm tool
  • Implement the app VM integration with the desktop environment
Edited by Ribbon