Can We do Kernel Programming with Mojo ?

[jenushanjesuthasan]

Here are a few specific questions I have:

Can Mojo handle the task of modifying existing kernels? Are there any limitations or important things to consider when diving into kernel modifications using Mojo?

Is it practical to write device drivers with Mojo? Have any of you come across examples or best practices for building device drivers with Mojo?

Are there any other frameworks or tools you'd recommend for kernel-level development tasks like modifying kernels or writing device drivers? If so, what makes them stand out compared to Mojo?

[abhinav-upadhyay]

Here are a few specific questions I have:

Can Mojo handle the task of modifying existing kernels? Are there any limitations or important things to consider when diving into kernel modifications using Mojo?

Given that it is a systems programming language with unsafe features and no GC, it can be used for kernel development. I am not sure what you mean by modifying existing kernels. Do you mean, can it be used like Rust for writing Linux modules? I think that should be possible, given that modules are a binary interface.

If you mean can you mix C and Mojo in existing Linux kernel code, I am not sure about that.

Is it practical to write device drivers with Mojo? Have any of you come across examples or best practices for building device drivers with Mojo?

Are there any other frameworks or tools you'd recommend for kernel-level development tasks like modifying kernels or writing device drivers? If so, what makes them stand out compared to Mojo?

Right now the core of Mojo is still being evolved, so there are no frameworks or tools yet to do such work. I think once the compiler is available for install locally, people will start to do lots of cool things, including kernel and device driver development with it.

PS: These are just my personal obeservations, I am not a core Mojo dev.

[strangemonad]

Here's my outsider's hunch.

If you mean something like a CUDA kernel or some other accelerator kernel where there's a corresponding host async task representation (e.g. exposing abstractions over MLIR's async), then I'd say it's very likely to be a priority for "a language for the end of Moore's law".

If you're talking about OS kernel, while it could be possible, it's not trivial, and I wouldn't expect it to be a priority. You can look at the decade-ish progress it took for Rust. You have to support things like compiling without the std-lib, pluggable behavior of exceptions and panics, swapping out the memory allocator and supporting an async-runtime free version of everything. There's also a bunch that's still to be designed but it's unclear if mojo will provide all the explicit memory handling needed. E.g. in swift, one of the design choices was to promote objects over a certain size from stack to heap. It reduces the explicit coding syntax and ceremony you see in something like Rust but it wouldn't be appropriate in a kernel setting. My hunch is that the Mojo team is going to try and find some 80/20 balance of what Rust's borrow checker can provide with an easier coding experience.

My personal take: All that effort wouldn't be well spent for a language trying to be a programming model "for the end of Moore's law". My personal design opinion is that kernel code shouldn't be in the business of doing CPU bound (single threaded) or parallel compute task. The general (if somewhat oversimplified) trend is to manage security and HW state and get in and out of the kernel "quickly". Push programed DMA onto PCIe, CXL, NVLink. Push storage compute onto Nvme cmd queues and packet filtering onto HW accelerated NICs with memory mapped packet queues. eBPF is maybe an interesting reversal of that trend but I wouldn't be surprised if running the eBPF VM 100% in the kernel is a more temporary phenomenon.

[lattner]

Yeah just to clarify, when modular-ites use the word "kernel" they typically mean high performance numeric kernel which may be targeted at an accelerator or GPU or CPU etc. Secondary meanings are "OS kernel" or "Jupyter kernel", because the word is overloaded.

Mojo is a general purpose language and can be used to replace C use cases like Rust does etc, but that isn't where we're focusing initial development. That doesn't mean we're excluding it, just that the libraries etc aren't the focus for us to build. We hope the community will be interested in filling that in and building out the use cases in time though.

[Moosems]

Do you foresee it eventually being usable to write an operating system?

[lattner]

Sure, Mojo as a language should support everything you need for that.

[Moosems]

MojOS?

[ksandvik]

The little I know of Linux kernel development, full control of memory is utmost important, Rust kind of sneaked in nicely due to the borrow checker and no gc or automatic reference counting dependencies. Depending on the final mojo implementation that might also qualify. But if you want to do kernel development, especially drivers today, use C.

[drunkwcodes]

When it comes to kernel programming, energy consumption has become an important issue. As shown in the graph, C has an energy consumption of 1.0. Rust has a slightly higher energy consumption at 1.03, while C++ consumes even more energy at 1.34. Python, on the other hand, has significant room for improvement.

If Mojo's energy consumption can match or even be lower than that of C++, it would be a significant breakthrough.

Reference: https://www.techbang.com/posts/106699-ill-get-it-after-the-rest-of-the-article-today-instead-of-c

[lattner]

I think @abduld has interest in this.

[abduld]

We have not done @drunkwcodes , we have not done any analysis about energy efficiency (which is important for both usages of the work kernel :) ) . My guess is that Mojo would be in the top 2 or 3, since Mojo does not do anything fancy behind your back. We do need to study this however.

[strangemonad]

@abduld an aside related to energy and scheduling / tiling. The work by Vivienne Sze and team presented at nips has a really cool framework for reasoning about accelerator kernel FMA cost

• https://arxiv.org/abs/1703.09039
• https://slideslive.com/38922815/efficient-processing-of-deep-neural-network-from-algorithms-to-hardware-architectures

[abduld]

Thanks, yes aware of this work. There has also been quite a bit of work on the MLPerf side

[Saddibek1]

Hi. Have you tested this?

[david-ragazzi]

I think it's possible, and I hope that Modular provide some future support for those embarking on this adventure. I say this, because there will come a time when the kernel developers will need specific language features that may not be available in Mojo yet, such as direct memory manipulation (specify which memory address a vector should is, for instance), among others, which is crucial for the development of OS kernel features. So Modular could priorizes these features requested by kernel developers through "issues" section.

By the way, I believe Modular will support this as soon as the main AI demands are met in Mojo. Even because device drivers or even a complete operating system developed in Mojo, would be a great advertisement for Mojo proving that is really a general purpose language. Many developers of languages ​​like C/C++, who like such a safe and fast approach that Mojo offers, would be tempted to try it on its projects.

In Rust this has already happened with Redox OS, which is a complete operating system written from scratch in Rust: https://www.redox-os.org/

Its FAQ lists the benefits of using Rust for developing Redox OS:

Rust benefits

Less likely to have bugs
The restrictive syntax and compiler suggestions reduce the probability of bugs a lot.

No need for C/C++ exploit mitigations
The microkernel design written in Rust protects against C/C++ memory defects.

By isolating the system components from the kernel, the attack surface is very limited.

Improved security and reliability without significant performance impact
As the kernel is small, it uses less memory to do its work and the limited kernel code size helps to keep it close to bug-free status (KISS goal).

Rust’s safe and fast language design, combined with the small kernel code size, helps ensure a reliable, performant and easy to maintain core.

Thread-safety
The C/C++ support for thread-safety is quite fragile, and it is very easy to write a program that looks safe to run across multiple threads, but which introduces subtle bugs or security holes. If one thread accesses a piece of state at the same time that another thread is changing it, the whole program can exhibit some truly confusing and bizarre bugs.

But in Rust this kind of bug is easy to avoid, the same type system that keeps us from writing memory unsafety prevents us from writing dangerous concurrent access patterns

Rust-written Drivers
Drivers written in Rust are likely to have fewer bugs and therefore are more secure.

Currently supported devices

Mojo can met these benefits, and even more, with the MLIR features to make the OS even faster.

[ksandvik]

There are also options to focus on an OS with either AI-related workflow optimizations or then an OS where various decisions such as process priorities, memory allocation et rest are handled with AI-related algorithms.

[edilalves]

This is a good insight!

[Moosems]

Or an OS with an AI assistant built at its core? 😄.

[melodyogonna]

There is no reason why it shouldn't be able to do such low-level tasks. Mojo wouldn't have a GC and Modular is currently working hard to add low-level capabilities to the language. Even more important is the fact you can step down to MLIR and access even lower-level primitives.