Date: Thu, 6 May 2021 10:57:16 +0100 From: David Chisnall <theraven@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: WSLg update on 1-5-2021 - BSD / WSL Message-ID: <92a81582-7bd4-b9f1-04b6-cbcd5eb77893@FreeBSD.org> In-Reply-To: <0b3d6049-f6eb-f9d4-5f20-f09ac666e949@nomadlogic.org> References: <CAA-K0n%2BsJ%2BKmc3LitPiX_RLxcKv8aUcY9=cRiM7mx58NY5xs-A@mail.gmail.com> <0b3d6049-f6eb-f9d4-5f20-f09ac666e949@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92a81582-7bd4-b9f1-04b6-cbcd5eb77893>