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
___
