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

David Chisnall (theraven_at_FreeBSD.org) 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?

Thanks

-- 
gonzo