3 ms·

Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

by Thaxll 6y ago

stmw 6y ago
Can you elaborate re: issues and lots of work required? I think it's generally to be expected that non-C language support in the kernel would be hard...
- muricula 6y ago
  Here's the article the parent mentioned in passing, it may answer your question: https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability https://www.chromium.org/Home/chromium-security/memory-safet... It's very Chrome and C++ specific, but the problems will likely be similar in practice.
  - stmw 6y ago
    Ah, right, I'd read that - but it's for C++, so it's a bit different than the kernel situation, and I actually had a much more positive reaction to it ("wow, seems like C++<->Rust is actually pretty far along"). Guess both are reasonable takeaways.
gpm 6y ago
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 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.
- JoshTriplett 6y ago
  > 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 with notions like counted strings or bounded buffers could interoperate with each other without having to go by way of an unsafe C interface.
  - mlindner 6y ago
    Is there any work currently happening on this. I think this would be huge for many languages so we can finally graduate past the era of C ABI.
ender341341 6y ago
Most of the chrome teams issues stemmed from C++'s lack of an ABI, not wanting to deal with using unsafe around the C++ interfaces & not wanting to have to annotate c++ to export it to rust. I'd say the biggest questions for Linux that may be blocking here relate to LLVM not being available on nearly as many platforms as GCC (many of which will likely never be supported cause they're legacy systems that are only supported in the sense that they aren't purposefully broken) which limits it's use in any core-ish kernel systems.

Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

by Thaxll 6y ago

Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

stmw 6y ago

Can you elaborate re: issues and lots of work required? I think it's generally to be expected that non-C language support in the kernel would be hard...

muricula 6y ago
Here's the article the parent mentioned in passing, it may answer your question: https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability https://www.chromium.org/Home/chromium-security/memory-safet... It's very Chrome and C++ specific, but the problems will likely be similar in practice.
- stmw 6y ago
  Ah, right, I'd read that - but it's for C++, so it's a bit different than the kernel situation, and I actually had a much more positive reaction to it ("wow, seems like C++<->Rust is actually pretty far along"). Guess both are reasonable takeaways.

gpm 6y ago

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 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.

JoshTriplett 6y ago
> 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 with notions like counted strings or bounded buffers could interoperate with each other without having to go by way of an unsafe C interface.
- mlindner 6y ago
  Is there any work currently happening on this. I think this would be huge for many languages so we can finally graduate past the era of C ABI.

ender341341 6y ago

Most of the chrome teams issues stemmed from C++'s lack of an ABI, not wanting to deal with using unsafe around the C++ interfaces & not wanting to have to annotate c++ to export it to rust. I'd say the biggest questions for Linux that may be blocking here relate to LLVM not being available on nearly as many platforms as GCC (many of which will likely never be supported cause they're legacy systems that are only supported in the sense that they aren't purposefully broken) which limits it's use in any core-ish kernel systems.