 Welcome, I'm Alan Bison, Kelsey, so we're from Microsoft and we thought we will speak about a couple of interesting projects that we've been part of. So I will be speaking about the Windows subsystem on Android and Kelsey will be speaking about WSL Windows subsystem on Linux. So this talk is an idea to give you an introduction to what the project's all about and also talk a little bit about what we do with respect to Linux kernel and how you guys can probably get involved or contribute or help us do things better. So just a brief introduction of what WSL, sorry, it's easier. Is this okay? Yeah, so just a brief introduction of what WSA is. One of things that I want to emphasize on here is WSA is not built into Windows. It's built on top of Windows. And for whatever we'll be speaking today, I think Microsoft Windows is required. So you need Windows to run any of these things. So that's it. So we run WSA on top of Windows. It's not built into Windows and WSA is like another application on top of Windows. So we don't have anything that is modified in the Windows HAL or the Windows kernel to get this up and running. So it's just a simple application that you can install, double click, fire it up and then you have WSA up and running. So we'll get into more of what the details of the architectures and stuff a little later. But what we also, what makes this possible is Hyper-V for us. So we have to have Hyper-V enabled and then that's when we have WSA spinning up into a VM and storing there. So the one of the other things that we've done is to keep the AOSP as is and not modify it as much as we want. We want to use stock AOSP so that when we move between versions, it's easier for us to maintain. We probably have a few patches here and there for vendor site implementation, but most of it is stock stuff that is given to us by Google. So that's, yeah. So that's the story I was trying to tell you that it's built on top of Windows and not into Windows. I think the idea here is if we do have things that we put part of Windows and then when Windows moves or when Android moves, we have a ton of work that we create for ourselves, which we didn't want to do. So which is why the whole idea is to keep it separate. And that's what we've done. Minimize changes into AOSP framework. So we've done very little changes to AOSP and so what we have is a single MSI application that you can download out of the app store, install, sorry, out of the Microsoft store, install, and then it's a completely independent package that runs on top of Windows. And WSA is a product, not a platform. I think that's something we want to clarify to the world that it's just a simple product which you can install, run, and play around with. Yeah. Next one. Thanks. So this is straight from Google, but I just wanted to put it out there to say, all of this is just retained the way it is. Of course, there will be a few modifications based on the hall layer. One of the things that probably we've done is to disable Telephony completely. We don't have Telephony right now, but if you do have it in the future, it'll be basically a tablet with Telephony. Also I think Bluetooth is currently disabled for its own reasons. But most of it is retained as is and we'll get into the next slide, which will talk about details of the architecture and what we intend to do. Thank you. All right. So this is where I want to spend a lot of time talking about what WSA architecture is and why we've done, what we've done and stuff like that. So the most important thing is what you see on the right-hand side here. It's just a virtual machine that we launch. So one of the cool things here is we actually use WSL to launch the Android VM. And more about WSA will let us know in the future. Okay. So the whole thing is when we double click or let's say when we launch WSA, we have a Windows client application that fires up and launches the VM. So when we say it launches the VM, it's actually talking to something called the WSA service. So WSA service that is built into the Windows application, the MSI X application, which takes care of launching a virtual machine with its own configurations. So the configuration is probably like four to six GB of RAM and storage and stuff like that. And post that, that's the only thing that WSA service does. And then there's a VM that actually boots up. So the component that's probably missing in the diagram there is the Linux kernel, which boots up and then Android's launched. So this all happens inside of VM. And so that's the whole story about the WSA client, which actually is a very simple application which uses WSL to launch a VM and then everything else that happens inside the VM is standard Android. So the kernel boots up, launches all the user space and then we have the applications that you can probably install or run or stuff like that. So in the diagram we have the Android VM which I was just talking about. And then the slight blue box here is the Win32 application that is a bundle of all of this. So it's a simple thing. And this is the application that you can actually install from the Microsoft Store. So we have one instance of it running. If you close it, double click, it's just one instance. But if you have multiple users, different users, and each, there's an instance launched for each user in Windows. And then you have the cleaner publication to uninstall and stuff. So it's pretty straightforward. So what we also wanted to talk about is what we do with the kernel here. So we also, the fantastic thing that Google does is they give us a kernel. We currently on Android 13.5.15. And every month they have a kernel release with security fixes that comes out. So we move with the kernel, with whatever Google does. So we want to stay up to date with what Google's providing so that we have all the security fixes. But also we do have a few auto tree patches that supports Hyper-V and things around it. So this actually runs on both X86 as well as ARM. So I actually can show a demo a little later with WSA running on Surface Pro. So that's pretty cool. So we have these two platforms and so the kernel is like the core component for us. And we rely heavily on Google. And of course we have the rolling LTS model, which thanks to Sasha, we kind of got already implemented at Microsoft a few years back. So we follow that and then we do a monthly cadence release for WSA. And all of this source and the config and how to build and play around with it is all available on GitHub. So it's completely open source and you can just download, play around with stuff like that. So next slide if possible. So with that kernel component, what we also do have is the Android system side component. So we have all those images. And with that, we have these different states for the VM, it's either running state or it does not running transition stuff like that. So all of this becomes a part of the package that we deliver out of the Microsoft store. So it's pretty simple for end user to just go click and then get. So it's all bundled for you. And then you could probably, if you want to play around with the kernel, you could probably build your own kernel, replace it, do stuff. So the kernel comes from Google. So right now, I think we got the kernel just three days back, four days back. And we are on the latest 20, 20, 305, 515 tag with, it's 51594 that we have running on the current WSA release. And so the interesting bit here is we use this tag. We have feature branches, which we will talk about a little later, which is the audit record. And then we merge them all into the, on top of this tag and then build release. And this is available as in when Google releases this, we take about three or four days to do our own testing and we'll check stuff. And once that's done, we may get available on GitHub for the end users. And it's all there for you guys to see. I think we have, okay. All right. So the whole thing that actually makes this possible is Hyper-V. So I just wanted to put one slide out there to say, what, what, what makes this possible? And we've used Hyper-V for various different products. And for us, for WSL and WSA, this component is the most important bit, which is what lets us do virtualization on Windows. So it's a very brief of all diagram it's pretty much there, self-explanatory, but we have all of this stuff that's shown here being upstreamed and most of it is already upstream. So we have a team of fantastic engineers, dedicated working on Hyper-V and making sure that this is all available on upstream. And then I think the model here is pretty straightforward for us as to if you report an issue with any of these products, for us, it is to fix it upstream rather than have an auto-free patch where we fix it locally and then carry it and say, okay, this is fixed, but carry that patch forward for every other release. Well, what we want to do is to fix that upstream, pull it into every other product or put it into the main kernel that we use, even probably pull it into Google's, I think Google also uses LTS. So we want it to be part of LTS so that we base our work on the latest upstream LTS. And we have all this latest fixes and features part of that. So I think on that note, we have my last slide. All right. Some of the features that we really love. I forgot this one. Next to Google, we have all of these coming in, but I wanted to speak about PGO because that is something we still carry out of Tree. It is the work done by Keys and we still have this as a separate feature branch which we merge in because this is not in Google's Tree either at the moment. So with PGO patches, I think it was probably pushed in 5.14, 5.30. I'm not very sure. We've actually seen improvements, significant improvements. We've gained boot times, a lot of other improvements in the kernel. So we carry these patches now as part of our official drop into the Microsoft WSA kernel. And of course we have the Google's development model that we really love where we get all the security fixes and we get all the CVs fixed and they also use the LTS and stuff around it. So that actually makes our job a lot more easier in terms of getting the end customers stock and write our WSA that's running on top of Windows. So this is our official GitHub repository where we have where we push the WSA sources. So we have these tags that you see. We have the internal project name is called Latte. So we have Latte 2 which is the 5.15 and Latte is the 5.10. So we moved from 5.10 to 5.15 recently. So we publish these tags. It's out there for everybody to play around with it. So you can actually come back and report issues to us and then we would actually fix that upstream and then, you know, take that route of going into LTS and then into the Google stream and then back into Microsoft. So that's the whole idea of how we do things. If you have any questions so far, that'd be, or I could probably take the questions after the WSA stations also. Yeah, so I don't think we have anything that's newly written. We use everything that's available in the kernel. So let's say, for example, if you have to do an audio, if you have to play an MP3 at the WSA layer, all it does is to call into the AOSP's APIs and then into the kernel and then you have the fast HP socket that happens. And then that talks to the windows client that way spoke about and that talks to the windows hell and just place the audio. So we've not written any specific drivers or stuff like around it to make things working for WSA. We've stuck to the standard of standard way of how Google Linux kernel does it and then transition that from AOSP to the windows using the Hyper-V and the windows client and into the windows hell. So the idea, like I told you, is like we wanted to keep everything stock so that when things move forward, we move with it very easily rather than carrying our own out of free stuff and making life miserable for ourselves. I hope it answers your question. Yes. Yes. We've contributed back to upstream, which has gone into LTS and then into the Google stream and back into what we have. So yes, we have. So there are a ton of patches. I think most of our contributions have been around Hyper-V, which is the thing that we wanted to, but the team at Microsoft works on. And of course, we've had a few bugs, a few issues with the versions of Surface Pros, the version one and version two. I think some of them are still carried out of tree because it doesn't make sense for us to upstream the hardware's obsolete, but we still do test it on those hardware. But most of what we do on Surface Pro 2 or Surface Pro X and above is all part of Linux history. Yeah. So on that note, I'll hand it over to Kelsey to speak about WSL. And if you have any questions, so we could always do a Q&A after that. Thank you. Hi, everyone. So I'm Kelsey. I maintain the WSL 2 Linux kernel at Microsoft. Let me get right here. Apologize for the flashing screen. If it does go out, I don't think there's anything too important on the slides. We can talk through it. And also the slides are available on Sketch to download. So you can always reference that and the thing we talked about on there just in case. But I think it will hold on. So WSL is Windows, the subsystem for Linux, that basically what it allows you to do is be able to run Linux in Windows. So you can think of it kind of like a VM. It's actually, for WSL 2 is running on a lightweight VM, but it's very integrated into Windows. So what I want to apologize, I'm going to get a little bit of freeze brain while we're going through this, but we'll get through. So you can run WSL instances within Windows. It allows you to run multiple. So if you want to run Ubuntu and Cali at the same time, you're able to do that. It is integrated within the file system. So if you want to access your Windows file system within WSL, you can do that. There is a couple difference here. So as I keep saying WSL 2, there is two different versions. So we have WSL 1 versus WSL 2. WSL 1 was the originally released one. So it actually was not in a VM. And instead what would happen was how this was working was Linux subsystem calls would get translated into Windows subsystem calls. Now what changed is for WSL 2, now it is running on a lightweight VM, which allows us to put in the full Linux kernel, which WSL 1 didn't have. That gives us the ability to also have full system call capability, which is great. So you can actually do things like this gives advantage like Docker for exist. For example, you're going to be able to run in WSL 2. There is also performance increases. So if you're working on large projects and performance within WSL 2, that's going to work better than WSL 1. The one key point where WSL 1 does have the advantage is if you are working across the OS file system. So let's say if you have Ubuntu WSL instance and you are editing a bunch of files that are on the Windows side, you're going to see a decrease in performance on that. So you can still do it. It just is going to be a little bit slower on WSL 2 than WSL 1. But for the start, you're going to see a lot more perks within WSL 2. So here you can kind of see like a little graph. You can kind of get a vision. Do keep in mind again this is WSL 2 only. WSL 1 is not going to be, it's not going to have the VM or the kernel. So once you switch over to WSL 2, which by the way, these are both available in the Microsoft Store. You can download WSL 2 and it is as simple as running a command be able to switch between the two. So these aren't, you can't even choose to switch between them after you already have everything set up. That is definitely an option. You just have to remember that you're going to be losing anything that you, if you customize the kernel or any of those abilities that you would be losing if you switch over to the first version. So yeah, so you can kind of visualize here. One thing to keep in mind for this is there is only one kernel that you're going to have for all of your instances. So you're not going to have multiple kernels on your system. So if you are going to have, let's say for, if you're going to have the Ubuntu, like let's say you have two Ubuntu instances going, a Kali instance going, they're all using the same kernel. So I know I've seen a question being asked before if somebody could customize two different kernels, like maybe they want to run one kernel for one Ubuntu instance and a different kernel for another. It is one kernel. So you want to make sure that it's optimized for all of your, any of your instances that you have up and running. But it is easy to change your kernel, which is super nice. So instead of installing, you actually, you can still build your kernel even within WSL and then you want to put it within a path that you reference within your WSL config. Once it references that, you restart your WSL and it's going to boot into that kernel. So it is very easy to be able to customize your kernel, use your own. Maybe you want to use an upstream one instead of ours. We do work to keep pretty close to upstream, but if you want to be on like, even do like links next or keep with the latest and greatest mainline kernel then you do have the option to do that. Yeah, a couple of these other points here, kind of as I mentioned before is the increased IO performance. So that's within the WSL instances and then full system call capability with those are the advantages you get with the WSL too. So to talk about a little bit specifically about the kernel. So we are using the upstream long term support kernel. So technically right now WSL, if you're to download it from the store is going to have a 515 kernel have been working to update it to the latest 6.1. Ran into a couple, a couple bugs. So it's a little delayed, but I did just get a updated version released. So if you go to the GitHub, the new version is out. So it is now it's not currently in WSL, but it is on the WSL to GitHub page. So how this works is there is a WSL GitHub page and WSL to kernel GitHub page. They are separate. So I manage the kernel once I finish a kernel update, I upload it as a release to the GitHub. You're able to go on there and download it. You can. I do also include the the configuration files on there. So what we're building the kernel with so that way you can go ahead and take the same config so you know that what we're doing is that you can go ahead and change it and customize you please if you'd want to. You can also then see what out of tree patches we're adding. So this picture that I added here, it shows a list of Alan had mentioned earlier. We call them feature branches. These are out of tree patches that are not upstream. We try to keep this minimal and you can see in the list here it's each one of these little things where it says like merged and it's going to be a branch. These are all of our like feature or topic branches that we're merging in and each one's going to have a set. So if you go to the GitHub page after WSL to you can click into these and actually see what patches are getting added on top this way. You can see what differences are most of it is going to be documentation changes things about WSL to the configurations we have like the security one it's like it's a document for Microsoft security and then it's there's going to be some like hyper V related things. So if you do run your own kernel you want to customize I do recommend at least some of these like the features or especially if you do see a fix. Go ahead and adding those on top of your kernel so you can just at least come check what commits there are and then make sure to add those on because you can boot WSL to and run it pretty well with just the kernel upstream. I even recently tested 6.3 which is the latest mainline in that I was able to boot that fine but there is going to be some like hyper V things that you might run into just because of the additions we do that we have added on. We try to keep the outer tree patches super minimal most of the time if there is something we want to add on we're going to try to push for it to be upstream if it can't go upstream generally we're going to want a very good reason for that. So even like I'm not sure if this one is pictured there is a now the next release I did is right after this one I have pictured and you'll see like there's a fix but it is actually in a later version it's already upstream it's just not on the 6.1 21 so we're going to take them in but sometimes if there is an important fix if anyone's familiar with generally a normal like how maybe you bond to other girls like there's an important fix that's not in the kernel version we're doing we're going to go grab it back port it to ours and then of course once we do or if we're going to update it will eventually come but we'll reference that too in the commit if you're to look at the commit we'll say oh this was cherry picked from this commit upstream so we'll always reference that. So from here a huge part of our priority has been wanting to stay as close to upstream as possible contribute upstream as much as we can we haven't felt that we've been doing that as much as we would like to and that's a huge goal for us to be able to do that more so right now we've now and I both have increased our ability to at least be testing release candidate kernels so release candidate kernels are ones that are getting really before they actually get released like for the actual update so at 5.15 there's like some bug fixes that are coming up there's generally like a two day period where you can go and you can test it's announced on the mailing list we can test the kernel we can either give a thumbs up where we can say this broke our system or here's an issue and we can help debug it and it helps to catch regressions before a release actually happens so we've both started doing our best to any chance we get to be able to test these release candidates and also another huge focus of ours right now is increasing our internal tolling we're trying to automate a bunch of things increase our testing capabilities so this way we can not only test our own kernels and our own products a bunch more be able to catch regressions before we do releases but also be able to do that upstream as well so a huge part of it of course if we catch it upstream that's going to be helping us and then everybody else as well the idea is once we hopefully have a better internal system where we're doing these automated tests and so forth is we're hoping to be able to have more time to be able to go upstream help with back parts that maybe had failed or got missed be able to contribute to the mailing list whether it's reviews or also contributing ourselves doing fixes and contributing new features as well so that is our current goal that we're working towards and we're definitely excited to be able to contribute upstream as much as we can and it's absolutely a huge focus of ours and yeah that is one thing I did kind of forget to cover at the very beginning was just kind of referencing WSL and WSA there was a lot of similarities in the way that they work and then the way that we also maintain their kernels so I'll do a great job like covering a little bit more of the architecture and like with Hyper-V and doing that so that might be why I steer away from kind of trying to repeat too much on that so yeah I guess any questions for WSA or WSL wonderful okay do you have questions or if you do actually want to see anything I have my computer WSL on it of course and then I'll mention you have your Surface Pro so with WSA programs on it so feel free to find us if you have questions or want to talk about things or even poke around and kind of see how things work absolutely we're more than happy to so yeah thank you everyone