 Hi, my name is Gianluca and this talk is called Everything is a Device, it's based on my current project, which is a personal project and yeah, the subtitle gives you an idea to my style of developing this project. Anyway, so who am I? I am a programmer, mostly I currently work in a company which is in stealth mode, which is called Zidida back in Santa Clara. I personally live in London. In the past I worked for a random company, some good some bad. And in the open source world I mostly been affiliated with the Minix 3, the GNU Hard and the Xen. As you can see, essentially I'm an advisor and operating system is what I've also been working mostly in my life. So the things about me is that I create a lot of personal projects and mostly I do it for fun. I don't really think about getting like the next big thing. I just like to learn new stuff. I just need to satisfy my curiosity and yes, I need to have fun. And this is one of my personal projects. It's not curiosity in the sense that it's my first camera that I write. It's one of my old dobbies. But anyway, that's what we're going to talk about. Anyway, the outline of this talk is the following. So I was going to introduce MH and MLG. So I already introduced MH in the FOSM on 2016, but for people who are not there, it's going to be interesting. It's going to be another introduction. Also, things have changed since then. Then I'm going to explain the kernel architecture to explain better how it creates such a system. And then I'm going to speak about something which got me excited very recently, which is the RAM kernel and usually using the kernel components of NetBSD inside MLG, inside the user space. And also running unique kernels in such a system. And how easy it is to take anything and run a unique kernel on it. It's very interesting. Finally, if you have time, a conclusion and then Q&A. So I like questions. So in case you want, and I'm not offended if somebody interrupts me. So in case you have a question, just feel free to ask me anytime. Okay, this is an introduction to MLG. So what is it? Okay, so as you can guess by this room, it's a microkernel. Its name is Mujak. You can read why. And yeah, so this has been essentially a background personal project of me. I never had a full-time investment in it. And I actually started in 2015, in 2016, I introduced it. I had fuzz them in this, in this dev room. Then on mid-2016, for a complex issue, I had to put the project on hold. That could start working on late 2017. And so I've been working since back and forth because I started a new job. So things have been very hectic, but the five minutes a week I work on this project. And this is about what I got, what I achieved, and what we can do about it. So why MH? There are mostly three reasons. The first reason is that when I started, I really wanted to build a system. So I realized that like with modern systems, with modern Linux, especially, I cannot rent about Linux on desktop. Anyway, with modern Linux, I lost control of the machine. The things I like about Linux at all times is that when you boot it, you see your computer. I lost control of what my machine is, what the hardware looked like. And this is what I wanted. I wanted a system that I can boot in it. I can play with the device. I can play with the hardware. I can talk it. I can see what hardware I own, which of course, like with the modern Intellect Detective, is very hard anyway. But at least we try. And then I also wanted to experiment with software. And it's fun to create modular systems, let's create a system that interacts with hardware, but you can actually also start to do random things. They use hardware in different ways. I use the word experiment, but actually I mean fun. And yes, it's actually nice to try something relatively different because it cannot be completely different, because it's going to be a kernel, it's going to be a user space, it's going to be a Lipsy. It's the same thing over and over again, but you change something and you look interesting. And yeah, it's quite fun to be honest. One of the things I was trying to unexpected when I started this project is it's really fun to see the extension of my friends, especially the one who understands about operating system. When I tell them that I'm building a system where everything is a device, it's really fun. The strange look of disappointment and questioning that they have. It's really fun. And so actually this is the energy to which I'm continuing this project. So what is the image architecture? The image architecture is that everything is a device. So what does it mean? Well, it means that like the physical hardware that is presented in the kernel is actually exposing the user spaces of the device, but also all kernel services, for example the timer or anything with the console and the office, the thing that come on the top of my mind. That is also exposed to the user space as a device. And the process exposed, for example, like mapping a kernel is like talking to a memory controller. And then a process itself, another process can actually become a device. And it would be really, well, you can guess if it's a user space device or not, but the fact that it creates a non hierarchical element in a system, it's nice because yes, it can be dangerous, but I don't care. I'm here for the fun. And so essentially I'm creating a parallel system, a system where I can experiment things. And you know, there's no way I can actually create a user space that behaves exactly like an hardware device. And you know, that's exactly what people are trying to do now with QEMI and other things. So it's okay. The interface itself for the micro-kernel is very low level. And I like that. So essentially when I connect to a device, essentially I see a bus with the device attached to it. Of course it's a bit different because I need to open the device. There's a G there, UID, et cetera, et cetera. And like the memory is lower, especially when you map the memory like you speak into a memory controller and then you're going to receive page fault and then you need to react to that. And when you fork, for example, the kernel is not going to copy and write magically the page. You're just going to receive a pages fault which tell you you're trying to write to a shared page, fix it now. And so it's the kernel which need to copy the memory. I like it. And then you know we have the system with call interface. Essentially the way I interact to a device is to very low level systems. So for example, I have IRQs. And each device on IRMemuse, I know that for device to write to my memory, I need to export memory to the IRMemuse. And I have IRPort because I like X36 and it's very impossible to simulate memory map anyway. So once I have this system that can essentially substitute what the file system is in Unix, I left the rest very unix-ish. As I said before, I had fork. That's why I don't choose something which is much more typical in MacroKana like capabilities and fine grade. This is control. I don't care about that. I want to have fun. And it's much easier to build system like this. It's much funner because the nice thing about Unix is to help you doing this. So this is an example to what I mean. And this is a magic way of slide that I use a lot because this is my 2016 presentation. So this is what the process sees. This is how the process interacts with the world. The user space process, to interact with another device, can program the IRMemuse. And the MMU can write to its memory. And the device is trying to send to my RQs and I'm going to map their RQs into signals. And then I can send essentially IRPort. So, oh, hello. This is essentially what it kind of looks like. But honestly, like as I said, I have a very low level system. So the question is another one. The question is how do I use it in the same way because I don't really want to handle page fault anyway. And that's why it essentially enters MLG. MLG is essentially like the runtime library, which essentially creates some interface and essentially some basic primitives. It was meant essentially just to handle the virtual memory, but then I started adding the fiber and event handling and memory management. And interestingly, I started to have the need of device divers for the device that I connect to. So essentially it starts to have library device divers inside MLG. And this is essentially what it is. MLG is a set of basic library. I've been creating my system, which is in the same other space, and some device divers that can run. And this device divers can be device divers for the other hardware, like for fake hardware. And yeah, and then what else does it have? It has boot up server and a console, which is quite interesting. Essentially, the boot up server is the first process that starts and that enumerates the devices. I will tell you in the next slide how it does that because it's quite interesting. And yeah, this is what it is. So this is the slide about the kernel architecture. It's a single slide, but I think it's quite interesting. So the way it works is this, like, as you can see, like the part about the scheduler, the CPU, the memory management, the PMAP, and the physical CPUs is relatively traditional. I repeat, I do some weird stuff on fork because I don't really have copyright and just protect the shared pages, but it's relatively traditional. What is interesting is the rest of the kernel, which takes, even on code wise, the majority of the thing, which is the device handling system. And the way it works is that you've got the system bus. And what the system bus does essentially, like every call in which I interact with a device go to the system bus. The system bus has essentially attached all the registers, all the devices that are attached to the system, like probably a file system, essentially, but with VFS essentially. And what happened when I do that is that then inside the kernel there are three or four types of devices that can attach to it. And the one I want to start for is the platform device. So essentially the platform device starts at the beginning. And as you can see, it talks directly with the hardware platform. The platform device is a device that exports IR ports, IR memory, and IR memory and IRQs, but all the whole systems. So essentially if you own the platform device, you can essentially speak to the hardware, whatever the port is. And this is what boosts up those. What boosts up those at the beginning opens platform. And then the current bus stop has actually ICPCA. And then actually it enumerates, it turns on the user space, ICPCA, and enumerate devices. And what it does then it creates these hardware devices. Other devices are exactly like, other devices are exactly like the platform device, except it sticks the access to only the resources of a single device. So for example, an example we'll see later, if we found the PCI-NT00020, which is the VGA usually, which is VGA compatible, what you get is you get a device for the VGA. What is cute, which I like, is actually I get the ACPI names for the devices, which give you a closer relationship with the guys who wrote the ACPI bios, which is nice. And anyway, so what I do essentially, I create all these devices and it's nice because then I can actually assign devices for a single process, more naturally than, for example, an app advisor does. And it gets quite interesting because then I can actually also list the devices and I can know easily what things are. And this is exactly what I want from this system. And yeah, so then what we have, the system device is interesting. I told you essentially it's a device which is fixed for all processes. It contains also the timers and dual clock timer and the virtual timer. But what's interesting is this one. This is how I implement user space devices. So every time a process interact with the system bus for a bus read or a bus write or something, it passes to a user device. It's a user device. A user device just for what the calls between the user space. And so even internally, it's the mechanism and the internal API user device is the same use for the other one. Anyway, this is, this is exactly what I just told you. And this is where it gets fun. So the problem with this is like I'm essentially like I was, I'm pretty sure that everyone in this room knows about lamb kernels, but what essentially they did was they create components out of the NetBSD kernel and the NetBSD system in general. And then they create a way for to merge this component together. And it's quite fun. And what I was interesting when I started looking at it is essentially I wanted the file system and the network drivers and the network stuff because I want to use somebody else's code on these things. And what I found, and that's amazing, is that actually putting the ramp kernel to your system is really, really easy because what they do, they have this component system. So the things you're going to fight is to make files. But it's okay. It's a plug-in of humanity. We haven't solved yet. So what they essentially do, they have this company which is called LibRamp user. And essentially what you do, it's actually a little, it's very post-execute, but it's easy to port to other architecture. And to me, it took me like one day to port LibRamp user to what I call LibRamp MLG. And when I got that, I immediately saw, it just compiled, the code just compiled. And so just by calling it rampinite, so you know, the copyright of the NetBSD kernel, which was beautiful. And it was fun. And I could see that NetBSD kernel was booting as Lib as a library. And then I actually added the component XT for FS. Did I say correct? SC for FS? Yes. And then I started calling mount, a device. And because I have my own library, a library ACI driver as a library. So I mounted it. And actually I could use in a kernel that doesn't have a shell, doesn't have any decent code, has just been hacked out five minutes a week for the past two years, except for one year and a half in which I couldn't. And I can actually get XT for HCI. And it's really fun. I feel like I'm doing something with my life, despite I'm not. It's amazing. It's really cool. Anyway. So yeah. And there's clearly some love between me, Rampkin and MLG, because what essentially happened is that the fundamental things where my system unexpectedly is close to Rampkennel is when, how can I say, like, what I need, since I have another space and everything is a device driver around me. I need a device driver. And since I'm a process, I need library device drivers. And that's what I was creating in MLG. Turns out that's exactly what Rampkennel gives me. And it's amazing because then I can actually do that. I can actually, I could actually even use the PCI device. And that's more complicated because I need to put a component called PCIU. But it can be done. It's beautiful. And yes, you know, then, OK, this is like me rambling about make files. So don't look. But yes, I can have network drivers as well. And it's very interesting to me. And what I like is that one is very convenient for me. But also it fits very well with my architecture, which was unexpected when I started. So especially when I had the idea in the pub. And I was drunk, by the way. This is the second part because this is actually a working process, a product in progress because I just got it done a few days ago. And it was, again, very easy and expectedly easy. So what is it? This is not Rampkennel. This is Rampkennel. So Rampkennel are unikernels. And what essentially Rampkennel is is a complete build of build of the Rampkennel. And it has also tools to create like images based on that. When I say Rampkennel, I say, oh, that's easy. I can just use Libramp-Emergy. But it turns out not because in order to run, it needs its own implementation of Libramp-users. So what Libramp-Ramp does is it actually creates an interface called VMK. And that's why you need to implement. It's actually much more low level. It's much more close to the real hardware. It looks more like the parallelized interface. It's quite strange. But anyway, that's what it does. And then actually, the ninth thing is that there's this step of three-to-equal Rampkennel packages that already had a lot of made unikernels. Really made unikernels. Like, they have big things like MySQL, Apache 2, Nginx, and MPG123. We'll see that. So this is fun because then I say, OK, it must be hard to port. And what was really, really hard this time is the fact that the toolchain that I use in MH was incompatible somehow with the expectation of the linker of the Makefile script. And I wasted one night on that. But it's OK. So what was interesting then, I actually said, OK, let's port Ramp-Ramp-Emergy. After fighting with Makefiles a lot, actually creating the BMK interface was really, really, really easy. And again, it took me two days of which, and then a couple of sleepless nights for the Makefile. But it was actually really easy. And what I did, then I created Ramp-Ramp-Bake and I decided to take MPG123, which is an amplifier. It just gave me a binary, which is a binary, a NELF binary for my MH. So OK, let's boot that. So I put that instead of the bootstrap and I booted into MPG123. So I don't have no shell or anything, but I do have an MP3 player. And with this, I actually conclude what I wanted to say, because as you can see, the goal of the system being fun has clearly been met. And it's really fun and I still don't know how much weird stuff I can do with it. And I like it. Yeah, so essentially, the things that really stuck me and I'm really excited about is that in a system like this, I can actually make MH, essentially a unicolon runner. And that's, to me, really interesting because it will make my project cool, because unicornets are cool. And, OK, of course, there's a lot of things to do and all the code is online. It's obviously licensed and I'm very tempted by GPL3, by the way, but for now I'll keep it PSD. And it's a bit scattered because it's my project and I am a bit scattered as a person in general. So if the code is there, please use it. Please have a look at it if you're interested. Please put lamp canons to your micro-canon now. And, yes, the code is there. So if you have any problem with finding the code or anything, just ask me. And any questions? This is where you find more information about it. Oh, question, hi. No, it's a security concern, which as you can see, since this is my project and I'm getting paid to do, I don't really care too much. Oh, sorry. The question is, the question was, excuse me, does the system require IMMU to run? So in order to be secure when you assign an hardware, essentially when you program the actual IMMU in the, here essentially, let me try to go back. So here, when you actually program the IMMU of the device, if the device is hardware, in a nice world, you should actually find which IMMU, in which IMMU busts the device sitting in program. I don't have the code for that. And it can be other because actually, I have implemented the ARVL locator, I'll do this, so it's just a matter of doing it, of having a device for the IMMU. So it's thinkable, I don't. Right now, what you do is what you do when you assign a device in a microchannel with other IMMU. You need to trust the device. So networking, device drivers, do you already use something like that? Do you, and if so, did you have any problems with removing the device driver from the rest of the networking stack? No, I have not. Can you repeat the question? Okay, that was a thing. That is to check if I have to listen to the questions. Okay. So essentially the question is, and the answer is no spoiler alert. Have you ever, have you ever, have you mentioned networking? Have you ever applied the networking of the NetBSD? And if so, of the RampKernel, have you had a problem desegregating the network stack with the driver? So no, I haven't, mostly because I need to implement PCI-util, and I want it to do in a cleaner way, because otherwise I cannot access the PCI-divers. And two, honestly, I don't plan into writing my own stack, so hopefully it's not going to be a problem. But no, I never had. But I think that it should be nice if there was an interest in RampKernel in people who are using it for micro-Kernels, to actually try to do that. That would be interesting. But no. This RampKernel stuff is like one week old, and I'm very excited and jumping up and down, essentially. So, okay. Well, there was a thank you page.