Supporting Linux kernel development in Rust

Post by snuxoll » Wed, Sep 02, 2020, 3:39 PM UTC

pjmlp wrote: post #356

snuxoll wrote: post #355

Earlier quoted context omitted.

The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward). C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to nat…

All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++. Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++). While everyone else just writes glue code with C like interf…

Post by danudey » Wed, Sep 02, 2020, 6:51 PM UTC

jcranmer wrote: post #38

JoshTriplett wrote: post #32

Earlier quoted context omitted.

Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly f…

> unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel). Does Linux even work with LTO right now? It seems to do a lot of weird-linking-magic things that I wouldn't expect to work well with LTO.

Post by mlindner » Wed, Sep 02, 2020, 8:27 PM UTC

JoshTriplett wrote: post #53

gpm wrote: post #22

Earlier quoted context omitted.

There is no doubt a lot of work here, but C Rust interoperability is a lot cleaner than C++ Rust. And for what it's worth, for almost all langauges C X interoperability is a lot cleaner than C++ X. Since almost all languages (including rust) "speak C", both in terms of compiler support and and being able to map every important C concept to a concept in their language. The same isn't true with C++. One thing to worry…

> One thing to worry about with adding any language (including rust) to the kernel, is that the next good looking language will probably interoperate well with C and not interoperate well with Rust. So there is a much higher cost the second time you try to add a language. This is something that Rust is acutely aware of. There have been many discussions about the idea of a higher-level "safe ABI", such that languages…