Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

141–150 of 240 posts

Re: Upcoming Rust language features for kernel development

#141

Post by uecker »

gpm wrote: post #136
uecker wrote: post #127

Earlier quoted context omitted.

Some parts of the industry with a lot of money and influence decided this is the way forward. IMHO Rust has the same issue as C++: it is too complex and a memory safe C would be far more useful. It is sad that not more resources are invested into this.

I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††. Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a sol…

I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still think it is a mistake and highlights more the influence of certain tech companies on open source than anything else.

Re: Upcoming Rust language features for kernel development

#142

Post by gpm »

uecker wrote: post #141
gpm wrote: post #136

Earlier quoted context omitted.

I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††. Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a sol…

I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still th…

> First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C.

Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use?

> Second, I do not even believe that memory safety is that important that this trumps other considerations

In your previous comment you stated "a memory safe C would be far more useful. It is sad that not more resources are invested into this". It seems to me that after suggesting that people should stop working on what they are working on and work on memory safe C instead you ought to be prepared to defend the concept of a memory safe C. Not to simply back away from memory safety being a useful concept in the first place.

I'm not particularly interested in debating the merits of memory safety with you, I entered this discussion upon the assumption that you had conceded them.

Re: Upcoming Rust language features for kernel development

#143

Post by Pet_Ant »

arnsholt wrote: post #89
corbet wrote: post #62

Earlier quoted context omitted.

See, for example, the binder driver merged for 6.18. It's out there, and will land when it's ready.

In discussions like this, I sometimes feel that the importance of related work like the increasing use of Rust in Android and MS land is under-appreciated. Those who think C is fine often (it seems to me) make arguments along the lines that C just needs to have a less UB-prone variant along the lines of John Regehr and colleagues' "Friendly C" proposal,[0] which unfortunately Regehr about a year and a half later conc…

Oof. That's a depressing read:

> This post is a long-winded way of saying that I lost faith in my ability to push the work forward.

The gem of despair:

> Another example is what should be done when a 32-bit integer is shifted by 32 places (this is undefined behavior in C and C++). Stephen Canon pointed out on twitter that there are many programs typically compiled for ARM that would fail if this produced something besides 0, and there are also many programs typically compiled for x86 that would fail when this evaluates to something other than the original value.

Re: Upcoming Rust language features for kernel development

#144

Post by nicoburns »

a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

> shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

The language co-development isn't unique to Rust. There are plenty of features in GCC and Clang that exist specifically for Kernel usage too.

Re: Upcoming Rust language features for kernel development

#145

Post by ameliaquining »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. (https://rust-lang.github.io/rust-project-goals/2025h2/ergono...)

Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solutions—but the purpose of this particular feature is to make it easier to write code that uses reference-counted pointers and reduce how much stuff the programmer has to keep track of. It doesn't let you do anything you can't already do, it just makes it less clunky. So if people can't easily understand what it does, then that's bad.

Re: Upcoming Rust language features for kernel development

#146

Post by nicoburns »

humanrebar wrote: post #133
aw1621107 wrote: post #85

Earlier quoted context omitted.

> Only if you primarily work with `cargo` and want to interact with C from Rust. In what way(s) does Rust's C interop depend on cargo? > The other way around has far less support and `rustc` does not standardize the object generation. I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting…

> In what way(s) does Rust's C interop depend on cargo? Do rust and cargo allow for multiple interpretations of the same C header file across different objects in the same program? That's how C libraries are often implemented in practice due to preprocessor tricks, though I wish it wasn't normal to do this sort of thing.

I would expect so. Rust and Cargo don't consume C header files directly at all. They consume bindings generated by bindgen (or hand written if you prefer). So you could probably generate mulitple bindings if you needed multiple interpretations of a C header.

If the header files are consumed by C code that is then consumed by Rust then you'll have full support for what C supports because it will be compiled by a C compiler.

Re: Upcoming Rust language features for kernel development

#147

Post by steveklabnik »

humanrebar wrote: post #133
aw1621107 wrote: post #85

Earlier quoted context omitted.

> Only if you primarily work with `cargo` and want to interact with C from Rust. In what way(s) does Rust's C interop depend on cargo? > The other way around has far less support and `rustc` does not standardize the object generation. I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting…

> In what way(s) does Rust's C interop depend on cargo? Do rust and cargo allow for multiple interpretations of the same C header file across different objects in the same program? That's how C libraries are often implemented in practice due to preprocessor tricks, though I wish it wasn't normal to do this sort of thing.

Rust and Cargo do not build C programs, so, the answer to that is "no", strictly speaking.

However, some people use cargo's build scripts to build c programs, which then you can link into your Rust program. Support would then depend on whatever the person wrote with the script, which in my experience usually delegates to whatever build system that project uses. So it should work fine.

Re: Upcoming Rust language features for kernel development

#148

Post by [deleted] »

humanrebar wrote: post #133
aw1621107 wrote: post #85

Earlier quoted context omitted.

> Only if you primarily work with `cargo` and want to interact with C from Rust. In what way(s) does Rust's C interop depend on cargo? > The other way around has far less support and `rustc` does not standardize the object generation. I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting…

> In what way(s) does Rust's C interop depend on cargo? Do rust and cargo allow for multiple interpretations of the same C header file across different objects in the same program? That's how C libraries are often implemented in practice due to preprocessor tricks, though I wish it wasn't normal to do this sort of thing.

[deleted]

Re: Upcoming Rust language features for kernel development

#149

Post by William_BB »

School-Cotton wrote: post #130
William_BB wrote: post #65

Earlier quoted context omitted.

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

> What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Well, pretty close to that, actually! Rust will statically prevent you from accessing the same data from different threads concurrently without using a lock or atomic. > what's preventing me from using C++ atomics to achieve the same thing You might forget?

The first comment is the definition of a data race, not preventing race conditions. And data races are trivial (sure, no static prevention in C++)

Re: Upcoming Rust language features for kernel development

#150

Post by gpm »

remix2000 wrote: post #140
gpm wrote: post #107

Earlier quoted context omitted.

I'm not sure I understand the point of your comment at all. Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access"). If by addr…

The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance. Sadly, I don't know rustlang, so I can't tell if the inability to describe its features in more commonly used terms is due to incompetence or the features being irrelevant to this discussion (see the title of the thread).

The thing is you aren't really asking about a "feature" of rust (as the word is used in the title of the thread), unless that feature is "the absence of data races" or "memory safety" which I think are both well defined terms† and which rust has. Rather you're asking how those features were implemented, and the answer is through a coherent design across all the different features of rust that maintains the properties.

As near as I can tell to give you the answer you're looking for I'd have to explain the majority of rust to you. How traits work, and auto traits, and unsafe trait impls, and ownership, and the borrow checker, and for it to make sense as a practical thing interior mutability, and then I could point you at the standard library concepts of Send and Sync which someone mentioned above and they would actually make sense, and then I could give some examples of how everything comes together to enable memory safe, efficient, and ergonomic, threading primitives.

But this would no longer be a discussion about a rust language feature, but a tutorial on rust in general. Because to properly understand how the primitives that allow rust to build safe abstractions work, you need to understand most of rust.

Send and Sync (mentioned up thread) while being useful search terms, are some of the last things in a reasonable rust curriculum, not the first. I could quickly explain them to someone who already knew rust, and hadn't used them (or threads) at all, because they're simple once you have the foundation of "how the rest of rust works". Skipping the foundation doesn't make sense.

† "Memory safety" was admittedly possibly popularized by rust, but is equivalent to "the absence of undefined behaviour" which should be understandable to any C programmer.

Post reply on HN