WSLg update on 1-5-2021 - BSD / WSL

Oleksandr Tymoshenko gonzo at
Fri May 7 19:07:07 UTC 2021

David Chisnall (theraven at wrote:
> On 03/05/2021 22:37, Pete Wright via freebsd-current wrote:
> > On 5/1/21 12:42 PM, Chargen wrote:
> >> Dear all
> >>
> >> please note that I hope this message will be discussed to get this on the
> >> roadmap for FreeBSD. Perhaps there is already talk about &&  work done on
> >> that.
> >> I would like to suggest having a BSD side for Microsoft FOSS ambitions 
> >> and
> >> get to know the BSD license. I hope the tech people here, know which nuts
> >> and bolts would be ready to boot a *BSD subsystem kernel and make that
> >> available on Windows 10 installations.
> > 
> > I believe most of the effort make this happen lies with Microsoft - it 
> > is their product after all.
> > 
> > WSL under the covers is Hyper-V which supports FreeBSD pretty well. I 
> > believe most of the work would be on the Windows side to get the 
> > plumbing in place to spin up a FreeBSD VM.  There are open discussions 
> > on the WSL github system where people have asked for this but it has not 
> > gained much traction by Microsoft.
> [ Disclaimer: I work for Microsoft, but not on WSL and this is my own 
> opinion ]
> WSL is actually two things.  WSL1 is similar to the FreeBSD Linuxulator: 
> it is a Linux syscall ABI in the NT kernel that implements *NIX 
> abstractions that are not present in NT and forwards other things to 
> corresponding NT subsystems.  Like the Linuxulator, it lacks a bunch of 
> features (e.g. seccomp-bpf support, which is required for things like 
> Docker and Chrome) and is always playing catch-up with Linux.  I'd 
> personally love to see a FreeBSD version of this (though I'd be 90% 
> happy if ^T did the *BSD thing), but it's something that only Microsoft 
> can do and is currently quite difficult because the picoprocess 
> abstraction in the NT kernel only allows one kind of picoprocess and so 
> it would need to add a new abstraction layer to support both.
> WSL2 is a lightweight Hyper-V VM that is set up to integrate tightly 
> with the host.  This includes:
>   - Aggressively using the memory ballooning driver so that a VM can 
> start with a very small amount of committed memory and grow as needed.
>   - Using Hyper-V sockets to forward things between the guest and the host.
>   - Using 9p-over-VMBus (which, I hope, will eventually become 
> VirtIO-over-VMBus, but I don't know of any concrete plans for this) to 
> expose filesystems from the host to the fuest)
>   - Starting using the LCOW infrastructure, which loads the kernel 
> directly rather than going via an emulated UEFI boot process.
> FreeBSD is currently missing the balloon driver, I believe, has a 
> Hyper-V socket implementation contributed by Microsoft (Wei Hu), and has 
> a 9p-over-VirtIO implementation that could probably be tweaked fairly 
> easily to do 9p-over-VMBus.
> The WSL2 infrastructure is designed to make it possible to bring your 
> own kernel.  I think FreeBSD would need to support the Linux boot 
> protocol (initial memory layout, mechanism for passing kernel arguments 
> in memory) to fit into this infrastructure, but that wouldn't require 
> any changes to any closed-source components.

Hi David,

Do you have links to the documentation on how to replace the kernel
and the boot protocols? Or any documentation for WSL2 internals?



More information about the freebsd-current mailing list