The Yocto Project on Windows

### Overview Presented at the Embedded Linux Conference Europe, speaker Alejandro Hernandez examines practical methods for utilizing the Yocto Project on Windows workstations. While embedded developers traditionally rely on native Linux environments to produce custom Linux distributions, Windows environments are frequently required or more readily available. The presentation evaluates existing containerized tools like CROPS (CROss PlatformS) alongside the Windows Subsystem for Linux version 2 (WSL2), detailing setup procedures, testing workflows, container integrations, and build performance across environments.

### Key Topics - **CROPS (CROss PlatformS)**: An established Yocto Project initiative leveraging Docker containers to offer OS-agnostic development environments across Windows, macOS, and Linux. Specific repositories highlighted include the Poky container and extensible SDK container. - **WSL1 vs. WSL2 Architectural Differences**: WSL1 uses a system call translation layer targeting the Windows NT kernel, which struggles with complete syscall compatibility and causes poor I/O performance on Git and Linux filesystems. WSL2 addresses this by utilizing a lightweight, built-in Linux kernel, providing full syscall compatibility and significantly improved I/O speeds. WSL1 is not supported by the Yocto Project. - **Environment Setup & Distro Management**: Verifying system compatibility (Windows build later than 18917 via the `ver` command), installing distributions such as Ubuntu or Debian from the Microsoft Store, and verifying distribution status and version using `wsl -l -v`. - **Custom Distro Creation and Testing**: Running BitBake builds inside WSL2, testing outputs via QEMU (`runqemu nographic`), and importing custom-built tarballs into WSL using `wsl --import` to run and extend custom distributions directly under Windows. - **Docker Desktop & WSL2 Integration**: Using Docker with the WSL2 backend directly from within WSL distributions to build container images and run CROPS Poky environments using shared host directories. - **Performance Benchmarking**: Comparing full from-scratch build times (with all source files cached locally, non-sstate) across WSL2, Docker, and native Linux.

### Technical Details Hernandez details practical commands and workflow mechanics throughout the talk: - **Prerequisites**: Windows build > 18917 is required for WSL2 support. - **Distribution Management**: Command `wsl -l -v` checks the version (1 vs. 2) of installed distributions, and `wsl -d <distro>` launches into a target environment. Distributions share a common Microsoft standard kernel (e.g., 4.19.x). - **Yocto Build & Emulation**: Building a Dunfell 3.1.3 release (`core-image-minimal`) using BitBake within WSL2. Testing is validated via QEMU with `runqemu nographic` (running kernel 5.4.x Yocto) or by exporting the built rootfs tarball and importing it into WSL with `wsl --import <name> <install-location> <tarball-path>`. When run in WSL, the custom distro shares the WSL host kernel rather than the compiled Yocto kernel, making QEMU better suited for kernel-specific testing. - **Extending WSL Distros**: A custom imported distro initially lacks development tooling such as GCC; it can be augmented either by installing the Yocto Project buildtools tarball (providing GCC 9.3) or configuring package managers like `apt`, `opkg`, or `dnf`. - **Performance Results**: - For `core-image-minimal`: WSL2 completed in 79 minutes, Docker in 82 minutes, and native Linux in ~69 minutes (roughly 10 minutes faster). - For `core-image-sato`: WSL2 took 108 minutes, Docker took 107 minutes, and native Linux took 113 minutes.

### Takeaways The performance delta between WSL2, Docker, and native Linux for building Yocto images is negligible for scratch builds when sources are stored on the Linux filesystem. Because WSL2 provides full syscall compatibility and strong I/O throughput without noticeable performance penalties compared to native Linux, developers can choose between WSL2, Docker, or native Linux based on organizational workflow and personal preference rather than performance constraints.