For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community!
I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has enough implemented to run most BusyBox commands on the console.
Major things that are missing at the moment: decent FS driver (only fat32 RO at the moment), and no networking support.
Cool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.
Congratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).
Copyleft doesn't work well with Rust's ecosystem of many small crates and heavy reliance on libraries alongside static linking.
If one library be GPLv2 and the other GPLv3 they couldn't be used together in one project. LGPL solves nothing because it's all statically linked anyway. And yes, one could licence under both under the user's choice but then GPLv4 comes out and the process repeats itself, and yes one could use GPLv2+ but people aren't exactly willing to licence under a licence that doesn't yet exist and put blind faith into whoever writes it.
Using anything but a permissive licence is a good way to ensure no one will lose your library and someone will just re-implement it under a permissive licence.
C is a completely different landscape. Libraries are larger and the wheel is re-invented more often and most of all dynamic linking is used a lot so the LGPL solves a lot.
Love the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.
Very impressive and I like how accessible the codebase is. Plus safe Rust makes it very hard to shoot yourself on the foot, which is good for outside contributions. Great work!
After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?
> I am a bit scared of a Linux ABI-compatible kernel with an MIT license.
What's the threat? Solaris/Illumos, the BSDs, even Windows, have all tried -sometimes more than once- to be compatible with the Linux ABI, and in the end they've all given up because the Linux ABI evolves way too fast to keep up and is underdocumented. Someday someone -perhaps TFA- will succeed in building momentum for a well-defined and highly functional least common denominator subset of the Linux ABI, and that will be a very good thing (IMO) regardless of their choice of license.
I guess you imagine that everyone will switch to Moss and oh-noes!-everyone-will-be-free-to-not-contribute-back!! So what?
FreeBSD already has Linux ABI compatibility and has for a long time.
I have to say the GPL trolling in this post is some of the worst I've ever seen on HN. Literally 99% of the comments GPL trolls coming in and thread shitting everywhere. It's genuinely disgusting.
Really neat. Do you have any specific long term goals for it? Eg, provide an OS distro (using Linux drivers?) to provide memory safety for security-critical contexts?
Also, are there any opportunities to make this kernel significantly faster than Linux’s?
The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to.
We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix.
Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
Not sure why am getting in the middle of this but I need to point out that you are not even correct for Linux.
Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this.
As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open source Linux kernel on your Android phone? Probably not. You do not have the drivers. You may not pass the security checks.
Do companies like Broadcomm “collaborate” on Linux even in the PC or Mac space? Not really.
On the other side, companies that use FreeBSD do actually contribute a lot of code. This includes Netflix most famously but even Sony gives back.
The vast majority of vendors that use Linux embedded never contribute a single line of code (like 80% or more at least - maybe 98%). Very few of them even make the kernel code they use available. I worked in video surveillance where every video recorder and camera in the entire industry is Linux based at this point. Almost none of them distribute source code.
But even the story behind the GPL or not is wrong in the real world.
You get great industry players like Valve that contribute a lot of code. And guess what, a lot of that code is licensed permissively. And a lot of other companies continue to Mesa, Wayland, Xorg, pipewire, and other parts of the stack that are permissively licensed. The level of contribution has nothing to do with the GPL.
How about other important projects? There are more big companies contributing to LLVM/Clang (permissive) than there are to GCC (GPL).
In fact, the GPL often discourages collaboration. Apple is a great example of a company that will not contribute to even the GPL projects that they rely on. But they do contribute a fair bit of Open Source code permisssively. And they are not even one of the “good guys” in Open Source.
That's 1980s-90s thinking. Nobody is making proprietary BSD forks any more and new kernels probably have no chance of reaching production anyway so worrying about proprietary forks is irrelevant.
I think GCC is the real shining example of a GPL success, it broke through a rut of high cost developer tooling in the 1990s and became the de facto compiler for UNIX and embedded BSPs (Board Support Packages) while training corporations on how to deal with all this.
But then LLVM showed up and showed it is no longer imperative to have a viral license to sustain corporate OSS. That might've not been possible without the land clearing GCC accomplished, but times are different now and corporations have a better understanding and relationship with OSS.
The GPL has enough area to opt out of contributing (i.e. services businesses or just stacking on immense complexity in a BSP so as to ensure vendor lockin) that it isn't a defining concern for most users.
Therefore I don't think Linux' success has much to do with GPL. It has been effective in the BSP space, but the main parts most people care about and associate with Linux could easily be MIT with no significant consequence on velocity and participation. In fact, a lot of the DRM code (graphics drivers) are dual-licensed thusly.
This comment does not contribute to discussion of TFA: it's just license flamewar bait.
The authors almost certainly gave a bit of thought to their choice of license. The choice of license is a "business choice" that has to do with the author(s)' goals, and it is a choice best seen as intending to achieve those goals. Those goals can be very different from your own goals, and that's fine! There is no need to shame TFA for their choice of license, or implicitly for their goals as opposed to yours.
> Linux won specifically because the GPL forced the "greedy" actors to collaborate.
How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.
I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.
I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.
Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.
Kinda sad that the top comment on this really interesting project is complaining about the license, reiterating the trite conventional wisdom on this topic,which is based on basically two data points (Linux and BSD) (probably because any time someone tries something new, they get beaten down by people who complain that BSD and Linux already exist, but that's another topic).
This comment is a tangential distraction, but it's not even correct. Linus Torvalds has specifically claimed that he wouldn't have created Linux at all if 386BSD was available at the time. But BSD was tied up in a lawsuit with USL, discouraging companies and individuals from use.
very impressive! i think this is a far better approach to bringing rust's advantages to linux rather than trying to squeeze rust into the existing linux kernel. best of luck!
41 comments
[ 2.4 ms ] story [ 56.0 ms ] threadFor the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community!
I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has enough implemented to run most BusyBox commands on the console.
Major things that are missing at the moment: decent FS driver (only fat32 RO at the moment), and no networking support.
More info is on the github readme.
https://github.com/hexagonal-sun/moss
Comments & contributions welcome!
Also how does it's design compare with Redox and Asterinas?
If one library be GPLv2 and the other GPLv3 they couldn't be used together in one project. LGPL solves nothing because it's all statically linked anyway. And yes, one could licence under both under the user's choice but then GPLv4 comes out and the process repeats itself, and yes one could use GPLv2+ but people aren't exactly willing to licence under a licence that doesn't yet exist and put blind faith into whoever writes it.
Using anything but a permissive licence is a good way to ensure no one will lose your library and someone will just re-implement it under a permissive licence.
C is a completely different landscape. Libraries are larger and the wheel is re-invented more often and most of all dynamic linking is used a lot so the LGPL solves a lot.
Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp
Great project either way!
How do you decide which sys calls to work on? Is is based on what the user space binaries demand?
After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?
Could I swap Ubuntu's or Android's kernel with this, while keeping those OSes bootable?
What's the threat? Solaris/Illumos, the BSDs, even Windows, have all tried -sometimes more than once- to be compatible with the Linux ABI, and in the end they've all given up because the Linux ABI evolves way too fast to keep up and is underdocumented. Someday someone -perhaps TFA- will succeed in building momentum for a well-defined and highly functional least common denominator subset of the Linux ABI, and that will be a very good thing (IMO) regardless of their choice of license.
I guess you imagine that everyone will switch to Moss and oh-noes!-everyone-will-be-free-to-not-contribute-back!! So what?
I have to say the GPL trolling in this post is some of the worst I've ever seen on HN. Literally 99% of the comments GPL trolls coming in and thread shitting everywhere. It's genuinely disgusting.
Also, are there any opportunities to make this kernel significantly faster than Linux’s?
We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix.
Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this.
As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open source Linux kernel on your Android phone? Probably not. You do not have the drivers. You may not pass the security checks.
Do companies like Broadcomm “collaborate” on Linux even in the PC or Mac space? Not really.
On the other side, companies that use FreeBSD do actually contribute a lot of code. This includes Netflix most famously but even Sony gives back.
The vast majority of vendors that use Linux embedded never contribute a single line of code (like 80% or more at least - maybe 98%). Very few of them even make the kernel code they use available. I worked in video surveillance where every video recorder and camera in the entire industry is Linux based at this point. Almost none of them distribute source code.
But even the story behind the GPL or not is wrong in the real world.
You get great industry players like Valve that contribute a lot of code. And guess what, a lot of that code is licensed permissively. And a lot of other companies continue to Mesa, Wayland, Xorg, pipewire, and other parts of the stack that are permissively licensed. The level of contribution has nothing to do with the GPL.
How about other important projects? There are more big companies contributing to LLVM/Clang (permissive) than there are to GCC (GPL).
In fact, the GPL often discourages collaboration. Apple is a great example of a company that will not contribute to even the GPL projects that they rely on. But they do contribute a fair bit of Open Source code permisssively. And they are not even one of the “good guys” in Open Source.
This comment is pure ideological mythology.
But then LLVM showed up and showed it is no longer imperative to have a viral license to sustain corporate OSS. That might've not been possible without the land clearing GCC accomplished, but times are different now and corporations have a better understanding and relationship with OSS.
The GPL has enough area to opt out of contributing (i.e. services businesses or just stacking on immense complexity in a BSP so as to ensure vendor lockin) that it isn't a defining concern for most users.
Therefore I don't think Linux' success has much to do with GPL. It has been effective in the BSP space, but the main parts most people care about and associate with Linux could easily be MIT with no significant consequence on velocity and participation. In fact, a lot of the DRM code (graphics drivers) are dual-licensed thusly.
The authors almost certainly gave a bit of thought to their choice of license. The choice of license is a "business choice" that has to do with the author(s)' goals, and it is a choice best seen as intending to achieve those goals. Those goals can be very different from your own goals, and that's fine! There is no need to shame TFA for their choice of license, or implicitly for their goals as opposed to yours.
How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.
I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.
I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.
Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.
What have you done?!