 My name is Marcel, I work for the Intel Open Source Technology Center, and this is a really short one. I give on something that is pretty much what I call L-Run, which is a small pad project of mine. It's pretty much something trying to get this a little bit more into a more usable state for other people. So before I get to what it is, it originated out of TestRunner, and probably nobody knows about this. TestRunner was a pretty much another script, I had to do it in C. It was a tool that I could just then start random kernels with my current file system and just test it if something worked or doesn't work or run in unit test or an automated test or something else. It is pretty much something, I don't pretty much, I think people recognize that in the movie, right? No? Come on. It's inception. So it's pretty much, you have your, you have your, build your kernel, you hold your tool or anything else you have modified, but you need to run this in a kernel. So the options you're going to have, you either boot that kernel, you run it inside a KVM or you do something, I think, else, which takes a lot of time. And time is the one thing that really annoyed me that to waste there. So this was pretty much a rep around KVM or QMO, and then it pretty much spawns itself again, starts itself up as in it and sets everything up and then drops me back into the shell and the location I currently was. So at the end of the day, I was running inside a new kernel, but with my current system that I had been running, so I could just quickly test out if this actually kernel patch works or I didn't use a modification that needed a different kernel. I didn't want to boot that kernel on the system because I have other things to do there and so on and so forth. I didn't want to put in an extra system. From a command line, it was pretty much simple. So it was written for Bluezy for the Bluetooth support and I just give it the kernel image that I've built and then I give it a bash and then I'm back there. I don't know if there's any other tool or anything else, but it just runs it and I got back to where I needed to be. Kind of interesting if you want to actually bisect something because you have found an issue or something else, you just can run this multiple times and you can build this up. So what it really does, it first of all starts KVM with a bunch of options because if you want to set up KVM manually, you need probably like 20 or 30 options to get this every working and everybody knows this. Most people script this, but then you move that script on a different machine. You have it somewhere else. You can't remember this one. Then you have to tweak a little bit because it's different. So I wanted something that can start KVM for me and make this work, especially if you have like, if you nested virtualization because you're already running a virtualization, make sure it does the optimal speed and so on and so forth. It uses plan nine resource sharing. So it's a file system from old days where pretty much you can pass through the host file system into your guest, which is kind of nice. It starts itself. So once you actually started, it forked itself again and became PID one. But then you had nothing there. You needed to do something else. So it sets up the basic file system. It mounts the different extra petitions that you need and so on and so forth. It does process management because once you're PID one, you have to do process management. If you want to start anything else, you actually need to manage something and figure out when it terminates so you can actually clean up after you. Cleaning up KVMs is actually kind of nasty in some certain situations. So you actually have to do this the right way. Interest thing for most things I do is testing. I need to have a D-Bus setup. So I need to spawn D-Bus demon, but to do this, I can't use the one in the system because of different privileges, different setups. So it has to actually mount the configuration files as in TempFS, create the files for this one, set this all up, or get the right permission and so on and so forth. Something I don't want to keep doing all over again, it did it just for me. Then if I were to do this testing, it needs to start the demon because with a couple of test cases, I just wanted to run the demon. Again, it needs another configuration setup. It needs to have the right permissions and so on and so forth. Have to make sure that D-Bus is started first, then you start the demon and so on and so forth. And then a couple of other tools that you needed to get going and make work. So it did all that for me, and then I could just actually write my unit test and then run this. In some cases, then you need also files, device setup. So with Bluetooth, I needed a virtual device or pass through. So it sets up all of that one. I could even have the device emulated in the host or in the guest and everything set up so I can pretty much just run the test quickly. So as you might have realized, this is all pretty much Bluetooth specific. But it served it well as a purpose. I thought, well, nobody needs this anyway. It's just a teeny tiny pet project. It works there. We can use it. We can utilize it and so on and so forth. So about five years ago, we started IWD, the new Wi-Fi Demon for Linux, which I'm probably giving a talking about now also. We ended up having the same needs. We need more testing. We need more unit tests. We need to run this. And we don't want to waste any time. The guys working on the project fork test runner and made it completely Wi-Fi specific. The code base doesn't look alike. You might see some resemblance. It is called the same. It works completely different. Besides starting KVM, it's a different beast. It starts KVM with different options and so on and so forth. Mainly because it is targeted at a test suite. It has a HW SIM setup. It needs to start host APD with 30 million different configurations. It does physical PCI pass through, since most Wi-Fi cards are PCI, not USB, or something else. And it actually has extra logging information that needs to get back to those. So completely different. So about three or four months ago, I said, OK, we need to actually get this unified because I don't want to end main two code bases. So instead of calling a test runner, which is an awful name, I called it L-Run, so that you can actually run a Linux kernel inside your environment and then do their testing. I stepped away from KVM and QEMO for a bit, because even if you have a fast system and a fast machine, it still takes a lot of time to set this up. Even with all the modern tricks that we have done with clear Linux and all the other works, it still takes me too much time if I want to run something. So I went back to something really old, called user mode Linux. Anybody remember this one? I think it's pretty much died out. I got back a little bit in the last couple of months or so where I set some external features. It actually works pretty well. And if you don't need any specific timing or actually real hard access, it's awesome. It's a lot faster. So instead of Plan 9, use hostFS. You get shared access to your file system. You get back where you need it. And then I said, OK, look, I can't have this all splitting up and hacking the configuration parameters for everything into the source code. I need some sort of configuration setup. Initially, I thought I can use just systemd units, point them to the units of the demons that I want to start, extract the parts that I need off of this one, and then start them up. It doesn't really work this way. Systemd is way too smart for this one and has way too many options. And if I would end up doing this one, I would re-implant systemd from the scratch. So I pretty took the basic ideas out of systemd unit files so that you actually have some basic options that you can use and you're familiar with. And then you can point this at your L run binary, and then it starts up the needed things you need. The process managed to have to got a lot smarter and in more details to actually get certain things working, especially since we have ported most of the demons over to more advanced configuration settings and more hardening support for security purposes. So it needs to have a lot of more work to do to set this up. You cannot just start a demon. I hope everything works fine. So this is how this actually looks like. If you're in a simple case, you just start L run. It will find an image in your current directory, and it will just boot it. Ignore the error on the second line. That's a user modlinux bug. I haven't really figured out how to fix this, even if you give it the right buffer. But what it pretty much does is it actually boots up, starts a file system, mounts a file system, creates the extra files, et cetera, and then drops you in the shell. So later on the bottom, you see if you do an ID, you are root now. And if you do a uname minus a, you actually are on a 5.3 colonel now. This was running due on a 4.2 Fedora colonel straightforward. So it drops you right into your testing colonel that I was building there. I can do my tests. I do control D. I'm back out. I can compile again. And it's pretty much fast. You can give it, if you want to do a little bit more smarts, you can give it a configuration file. The kernel command line options is pretty much important, because the queries are all hacked in. So I cannot tell them, OK, give me certain command line options, and you just pass this through to the user modlinux start, which is kind of nice. For the Wi-Fi testing, we always need to silence the radios, because otherwise I have to start deleting them after I boot it. The standard kernel decides to start with two virtual radios, which is kind of annoying, because they're always in the way. For the Bluetooth testing on a Bluetooth security vulnerability, I had to add a couple of options that are disable, kind of nice as well, and just give this option, then deactivate it. If you want to have some logging, because it actually starts, it creates a run shared directory where you get the log files back into your host file system. So you can run this virtual machine, and then it starts right in this file system, and then you get this back in your host file system, and you can view the log, which is kind of neat if you actually have to see what's going on, and it's pretty much automated. You can do this with any kind of logging as well, and I probably have to make this configurable, the shared directory, but this is for current work. If you want to start a virtual Bluetooth interface, it pretty much starts at, OK, start me two of them, and then it tells you what demon to start, and then you're pretty much it. It only has to tell you, start the logging first before you start the demon, and that's about it. For the tricking part, you actually have to also give it the D-Bus things. If you want to actually do testing on D-Bus, it has to actually just start the D-Bus. So I utilize this in socket activation, and then starting the D-Bus program as well, that one. It's all part of the Embedded Linux library. The main reason for this is one for us. This is the main core functionality that we're going to have. It contains everything that we need. All our communications demons don't need anything else. They just need this library, because it contains net-link, D-Bus, and everything else support. So we don't have this massive amount of dependencies when we have to build anything. Nice thing is, when we actually do this, we can use user mode, time travel mode, which is kind of neat. So every time the system is not doing anything, it jumps forward, which is great if you just have to wait 10 seconds for a timeout, because that turns into pretty much zero time. So unit tests and testing tools run really faster. It kind of works. The configuration of this one is a little bit nasty, and I hope maybe we can extend this a little bit in making this more fine-grained to switch it on and off at a given time, so I have to figure out how to do this. D-Bus Broker still doesn't fully work, mainly because it relies on having a journal active and socket activation fully working. So with D-Bus Demmon, you can just start it, because that does everything for you. D-Bus Broker needs a lot of work. It has to be pretend to be running in a system-D environment. So that's a little bit of I have to still add to this one to pretend to be at least a basic system-D environment for a bunch of tools to work. We have to do this for ourselves anyway, because we switched for IWD to all the security hardening options, so where the configurations file live, where the state directory lives, et cetera, so that eventually at some point we can run with dynamic user to spawn in a separate user every time the Demmon starts. So that needs a little bit of extra work, but it's not too much. I want to port KVM and QEMO support that we had in test run back to this one. So if you say, okay, I actually want to run this in KVM, you can, mainly because you have some PCI hardware that you want to pass through, or you have some USB hardware that you want to pass through, or something else. User Modlinux has a patch for USB path through. It doesn't compile anymore, it doesn't work anymore, and I think it's a lot of extra work to actually get that one back into a usable state so someone can use it. PCI, I think that's a no-go on the user Modlinux site. I also played a little bit with namespaces, so if you don't need a new kernel, just need your clean environment by your configuration files and state files, et cetera, live, because you don't want to overwrite your current usage of your Demmon. Namespaces would be probably enough. You can achieve something similar to system D run. I have to toy with this one, but I think it gives you a nice thing to test this quickly with a pre-built configuration environment, or if you have some other tests around that actually just need a different environment instead of just a new kernel. What I really want to do is get to the level where we can just say, look, it's nice to do the small testing, but you need a more complex system so that we can actually just spawn, have a basic setup as PID 1, and then give system D the full control to actually keep running in say look. Here's your files. We have built a minimal service unit files for you. Please start them, execute them in order, and then you have system D up and running. This would solve the problem having to emulate everything for D-Bus Broker, et cetera. It doesn't fully work yet. I think I'm gonna make this working eventually. Maybe we need a couple of patches for system D, but that would be a nice thing. We can just drop it into a new kernel, start system D up and running, then you have something like the system D end spawn, but you actually have it with a different kernel instead of just namespaces. I wanted to batch processing of unit tests as well, pretty much to integrate this with Git bisect. So if you have a couple of issues somewhere, if you just start it, go here. Here's the source code of your Linux kernel. Figure this out, build it, and tell me which kernel version fails, so it actually starts running all of this one. Instead, you have to do this a lot of manual things, which is, this will obviously not be fast. It will still take some time, but I don't wanna put this on a system where I have to do this manually all the time. So this is something I'm currently working on as well. And that's pretty much for the small pet project of mine. So, questions? So when you're using QMU, it will support cross compilation and things as well? So, no, the reason for this one is pretty much because I'm dropping in my current system that has all my current binaries. So if I would drop this in a PowerPC kernel on x86, all your binaries are kinda gone. It defeats a little bit the purpose. For that one, you'd have to have a system that you have pre-built and that you have to give the SFI system. So with hostFS and plan nine of 9PFS sharing, it doesn't make any sense. Would be great if you could do this, but then you had multibinary things where you have multiple versions of your code in it. So no, that we don't support. I'm not going to, by the way. Sure. Have you, I understand that this project is kind of helping you with continuous integration of kernel drivers? Yeah. Have you had a look at the built-in kernel functions to track branch and code coverage in the Linux kernel? No, I haven't. I highly recommend to do. I built a similar system some time ago and it gives you basically code coverage of your tests in your kernel. I'm gonna have a look at this. This is more for while you're developing. You wanna just quickly jump in the kernel test if your change works and jump back. That was the main goal for this one, not something like MoxTen's one. I will gonna have a look at this one and see if I can make use of it. Thank you. Thank you Marcel. Thank you.