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

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

601–610 of 853 posts

Re: Rust in the kernel is no longer experimental

#601

Post by estebank »

chippiewill wrote: post #567
embedding-shape wrote: post #446

Earlier quoted context omitted.

> supports 14 of the kernel's 20-ish architectures That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

They probably get a few for "free" from LLVM supporting them

LLVM platform support is neither sufficient (rustc needs to be taught about the platform) not technically necessary (you could write a rustc backend that targets a platform that LLVM doesn't, like modifying cranelift or once the gcc backend reaches maturity).

Re: Rust in the kernel is no longer experimental

#602

Post by jwatte »

jlrubin wrote: post #573

@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.

"Linux kernel devs tried Rust in the kernel -- you won't BELIEVE the reaction!"

Re: Rust in the kernel is no longer experimental

#603

Post by 9rx »

jlrubin wrote: post #573

@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.

Isn't successful already implied?

Unsuccessful experiments have no end unless motivation to keep trying runs out — but Rust seems to have no end to motivation behind it. Besides, if it were to ever reach the point of there being no remaining motivation, there would be no remaining motivation for those who have given up to announce that they have given up, so we'd never see the headline to begin with.

Re: Rust in the kernel is no longer experimental

#604

Post by acdha »

jacquesm wrote: post #510
acdha wrote: post #491

Earlier quoted context omitted.

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to suppo…

There was a time when it came to 64 bit support Alpha really was the only game in town where you could buy a server without adding a sixth zero to the bill. It was AMD, not Itanium that killed Alpha.

I remember that time being before 64-bit became a requirement for most people (I worked with some computational scientists who did buy Alphas for that reason since they needed the flat memory space without remapping hacks). The Alpha was indeed great but Intel did enough of a job convincing most manufacturers that the only future was Itanium that only a few niche workstation manufacturers picked up the Alpha, and they had 64-bit competition from SPARC, MIPS, and POWER pretty quickly.

I do agree that it was AMD which really made 64-bit mainstream. There’s an interesting what-if game about how the 90s might’ve gone if Intel’s marketing had been less successful or if Rick Belluzo hadn’t bought into it since he killed PA-RISC and HPUX before moving to SGI where he killed both MIPS and Irix and gave the high-end graphics business to nVidia.

Re: Rust in the kernel is no longer experimental

#605

Post by cratermoon »

jwatte wrote: post #602
jlrubin wrote: post #573

@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.

"Linux kernel devs tried Rust in the kernel -- you won't BELIEVE the reaction!"

One weird trick kernel developers HATE

Re: Rust in the kernel is no longer experimental

#606

Post by accelbred »

josephg wrote: post #444
accelbred wrote: post #180

Earlier quoted context omitted.

I've been working on Rust bindings for a C SDK recently, and the Rust wrapper code was far more complex than the C code it wrapped. I ended up ceding and getting reasonable wrappers by limiting how it can be used, instead of moddeling the C API's full capabilities. There are certainly sound, reasonable models of memory ownership that are difficult or impossible to express with Rust's ownership model. Sure, a differen…

I totally hear you about C friendly APIs not making sense in rust. GTK struggles with this - I tried to make a native UI in rust a few months ago using gtk and it was horrible. > Also, a more Rust-friendly model would have incured higher memory costs. Can you give some details? This hasn’t been my experience. I find in general rust’s ownership model pushes me toward designs where all my structs are in a strict tree,…

The code is written in an embedded style, i.e. no dynamic memory allocation or thread creation/deletion after program initialization. It's also prioritizing reducing memory usage over performance since we are targeting memory constrained devices (and our performance target is 10 tps and we have like 100k tps). Thus we'd use trait objects over monomorphization. Dynamic collections are also off the table unless backed by a fixed-size arena on the stack or static mem.

We heavily use arenas. We also have runtime-typed objects used to represent dynamically typed data like that obtained from JSON/Yaml or over IPC. If we were to be more friendly to modeling in Rust, we'd likely require that all memory reachable from an object node be in the same arena, disallowing common patterns like having list/map's arrays in one arena and having keys/strings in another or in static mem (this allows reusing other buffers without forcing copying all the data, so backing arrays can be smaller).

Re: Rust in the kernel is no longer experimental

#607

Post by kbolino »

zozbot234 wrote: post #582
kbolino wrote: post #547

Earlier quoted context omitted.

Great info! Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance. I think the answer to "can this be solved with editions"…

AIUI, this particular change would only impact some newly supported architectures going forward. These don't need to be buildable with older editions.

This feels antithetical to two of the main goals of editions.

One of those goals is that code which was written for an older edition will continue to work. You should never be forced to upgrade editions, especially if you have a large codebase which would require significant modifications.

The other goal is that editions are interoperable, i.e. that code written for one edition can rely on code written for a different edition. Editions are set on a per-crate basis, this seems to be the case for both rustc [1] and of course cargo.

As I see it, what you're saying would mean that code written for this new edition initially couldn't use most of the crates on crates.io as dependencies. This would then create pressure on those crates' authors to update their edition. And all of this would be kind of pointless fragmentation and angst, since most of those crates wouldn't be doing funny operations on pointers anyway. It might also have the knock-on effect of making new editions much more conservative, since nobody would want to go through that headache again, thus undermining another goal of editions.

[1]: https://rustc-dev-guide.rust-lang.org/guides/editions.html

Re: Rust in the kernel is no longer experimental

#608

Post by ls-a »

jwatte wrote: post #602
jlrubin wrote: post #573

@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.

"Linux kernel devs tried Rust in the kernel -- you won't BELIEVE the reaction!"

Use linux because it now has Rust kernels. Great marketing

Re: Rust in the kernel is no longer experimental

#609

Post by dang »

jlrubin wrote: post #573

@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.

Thanks! This is cromulent.

From https://news.ycombinator.com/newsguidelines.html: "Please use the original title, unless it is misleading or linkbait". Therefore: when misleading please edit.

Re: Rust in the kernel is no longer experimental

#610

Post by EMM_386 »

weinzierl wrote: post #271

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no goin…

I think Fedora 43 is compiled with CONFIG_RUST=y.
Post reply on HN