WSLg update on 1-5-2021 - BSD / WSL
Oleksandr Tymoshenko
gonzo at bluezbox.com
Fri May 7 19:07:07 UTC 2021
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
More information about the freebsd-current
mailing list