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

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.

Whether Microsoft or the FreeBSD project should do the work really comes 
down to who has more to gain.  Windows 10 is installed on around a 1.3 
billion devices and any of these users can run Ubuntu with a single 
click in the Microsoft Store, so it feels as if the FreeBSD project has 
a lot to gain from being able to reach them.  If you believe that 
FreeBSD provides a better experience (I certainly believe it provides a 
better developer experience) than Ubuntu, then making it easy to reach 
every Windows users is of huge value to the FreeBSD project and community.

Microsoft, in contrast, is driven by requests from customers who spend 
money on our products and services.  Around a hundred people commented 
on the WSL issue to add FreeBSD support.  If you assume that 1% of 
people who want the feature commented, then this gives around 10,000 
folks who really want a FreeBSD equivalent of WSL.  It's pretty hard to 
justify a feature in Windows that only 0.001% of Windows users will use. 
  If you want to change that arithmetic, then next time your 
organisation is renewing M365 or Azure service subscriptions, tell your 
sales rep that FreeBSD support is important to your company.  If, for 
example, a large company is spending a lot with a different cloud 
provider because they have better FreeBSD support than Azure, then 
that's the kind of thing that can be used to justify investing in 
FreeBSD.  Currently, from what I know of FreeBSD deployments in Azure, 
Microsoft is already investing a disproportionate amount in FreeBSD 
relative to the number of users.

WSL makes it easy for folks to develop on Windows and deploy in Azure. 
A lot of people are running Linux in Azure and so there's a big 
incentive to make this seamless.  If a load of people are deploying 
FreeBSD on Azure and can't develop on Windows as easily, that's an 
incentive for Microsoft to improve the FreeBSD client-side integration.

David