Rust kernel modules

Posted May 19, 2015 2:24 UTC (Tue) by voltagex (subscriber, #86296)
In reply to: Rust kernel modules by rillian
Parent article: Rust 1.0 released

Nice trick - is there a way to do it without the C shim?

(Log in to post comments)

Rust kernel modules

Posted May 19, 2015 10:44 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Nice trick - is there a way to do it without the C shim?

Probably not. Let's look at what this C shim has:

BUG() is an architecture-dependent C macro which calls inline assembly.

kmalloc() is a C inline function.

kfree() is not a C inline function, but should be kept together with kmalloc() for symmetry.

printk() is "asmlinkage", which is an architecture-specific calling convention, which might or might not be the same as the default calling convention for the architecture. For x86-32, for instance, it's regparm(0), while IIRC the default calling convention might or might not be regparm(3) depending on the kernel configuration.

module_init(), module_exit(), and MODULE_LICENSE() are C macros which do linker magic. You need the first one for the module to do anything useful, and the last one for it to not taint the kernel.

Rust kernel modules

Posted May 19, 2015 19:00 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, but not without some trickery.

Inline functions have to be reimplemented in Rust to remain inline, cross-language inlining would require whole-program optimization.

BUG can be reimplemented in Rust (yes, it has inline assembly support).

Linker attributes are currently missing, but they can be added.

Rust kernel modules

Posted May 19, 2015 19:17 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Inline functions have to be reimplemented in Rust to remain inline, cross-language inlining would require whole-program optimization.

Be sure to reimplement the kernel CONFIG_ system. Because some of these inline functions (like, say, kmalloc) change depending on the kernel configuration.

Don't forget to reimplement the data structures accessed by any of the inline functions. By the way, these also often change depending on the kernel configuration.

And don't forget that these inline function definitions are considered part of their own subsystem, so the reimplementation must be kept in sync with any changes to their subsystem. Changes which can easily happen on any minor release, since they're hidden within the inline function body.

Really, the only sane way to do it would be to either use a C stub to wrap all calls to macros or inline functions, or to somehow autogenerate the Rust equivalent from the kernel C structures, inline functions, and macros.

Rust kernel modules

Posted May 19, 2015 21:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>Don't forget to reimplement the data structures accessed by any of the inline functions. By the way, these also often change depending on the kernel configuration.
That's not a problem, any realistic project to integrate with the kernel infrastructure would use bindgen to automatically generate bindings for structure definitions and functions based on C source.

The trickiest part would be inline functions. And I think Rust is also missing a simple way to wrap unions.

> Really, the only sane way to do it would be to either use a C stub to wrap all calls to macros or inline functions, or to somehow autogenerate the Rust equivalent from the kernel C structures, inline functions, and macros.
It should be possible to eventually create something like Go's "import C" feature, that allows to automatically wrap C code in native bindings. Perhaps even preserving inline qualifiers by using Clang to compile C blocks within Rust code.

That's a sizable amount of work, but it's _possible_. And in extreme, Rust can be used just like pure "C" - simply slap 'unsafe' qualifier on your code and go mad with raw pointers.

From what I see, right now Rust is the only major language capable of replacing pure C/C++ even for the most low-level tasks.

Rust kernel modules

Posted May 19, 2015 23:22 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> From what I see, right now Rust is the only major language capable of replacing pure C/C++ even for the most low-level tasks.

Yes! That's what makes me so interested in it. IMO, it sits between C and C++, and adds a few very interesting new features of its own (like the borrow checker). And it has a gradual series of "escape valves" in case it feels limiting: unsafe blocks, inline assembly (in a future version or in unstable nightly), and as a last resort near-seamless linking to C (and indirectly to C++).