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

751–760 of 853 posts

Re: Rust in the kernel is no longer experimental

#751

Post by uplifter »

the_why_of_y wrote: post #710
uplifter wrote: post #630

Earlier quoted context omitted.

At least concerning Richard M. Stallman's take on this subject, this characterization is completely wrong. RMS certainly does not consider the difference between open source and free software to be merely one of 'emphasis.' According to him they are completely different animals. Here are his words on their difference[0]: > 'When we call software “free,” we mean it respects the users’ essential freedoms: the freedom t…

> Open source and free software mean almost exactly the same set of software > Nearly all open source software is free software; the two terms describe almost the same category of software. I see no disagreement, how is GP "completely wrong"?

Edit: I'm wrong on my first reply, as pointed out here: https://news.ycombinator.com/item?id=46226602

LLVM is free software, and it is a confusion to equate copyleft and free software, though I still maintain that free and open source are very distinct concepts which refer to different categories of licenses. That contrast is better stated by RMS in the article on the subject above which I linked above.

Original reply:

Primarily its this first line here:

>LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction.

LLVM is NOT free software because it is released under the Apache license, which is an open source license but not a free software license. This is opposed to the linux kernel and GCC which are free software because their source is available under the GPL license. Further it is not really a confusion to equate permissive licensing with open source as distinguished from copyleft and free software. In this context, free is equivalent in meaning to copyleft, as distinguished from the more permissive open source licenses.

Re: Rust in the kernel is no longer experimental

#752

Post by eru »

dzaima wrote: post #342
eru wrote: post #306

Earlier quoted context omitted.

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists, which iirc was a concern for the kernel? And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be abl…

> Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists, which iirc was a concern for the kernel?

That's a great point! A language almost like C plus a smart enough compiler could do the unboxing, but this technique doesn't work for multiple structures.

> And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be able to be chained in even if there are 0 bytes of free RAM ("Error: cannot free memory because memory is full" is probably not a thing you'd ever want to see)).

I think you are right in practice, though in principle you could pre-allocate the necessary memory when you create the items? When you have the intrusive links, you pay for their allocation already anyway, too. In terms of total storage space, you wouldn't pay for more.

(And you don't have to formally alloc them via a call to kmalloc or so. In the sense that you don't need to find a space for them: you just need to make sure that the system keeps a big enough buffer of contiguous-enough space somewhere. Similar to how many filesystems allow you to reserve space for root, but that doesn't mean any particular block is reserved for root up-front.)

But as I thought, that's about in-principle memory usage. A language like C makes the alternative of intrusive data structures much simpler.

Re: Rust in the kernel is no longer experimental

#753

Post by eru »

delamon wrote: post #527
eru wrote: post #306

Earlier quoted context omitted.

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

> if your compiler unboxes the contained item into your nodes Is there known compilers that can do that?

Haskell's GHC partially does it. LLVM can do it in principle, if your frontend gives enough information. Some JVMs can partially do some of it.

The above is about the optimiser figuring out whether to box or unbox by itself.

If you are willing to give the compiler a hand: Rust can do it just fine and it's the default when you define data structures. If you need boxing, you need to explicitly ask for it, eg via https://doc.rust-lang.org/std/boxed/struct.Box.html

Re: Rust in the kernel is no longer experimental

#754

Post by eru »

bluecalm wrote: post #553
eru wrote: post #306

Earlier quoted context omitted.

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

The main thing is that he object can be a member of various structures. It can be in big general queue and in priority queue for example. Once you find it and deal with it you can remove it from both without needing to search for it. Same story for games where it can be in the list of all objects and in the list of objects that might be attacked. Once it's killed you can remove it from all lists without searching for…

Thanks! That makes a lot of sense.

Re: Rust in the kernel is no longer experimental

#755

Post by steveklabnik »

uplifter wrote: post #751
the_why_of_y wrote: post #710

Earlier quoted context omitted.

> Open source and free software mean almost exactly the same set of software > Nearly all open source software is free software; the two terms describe almost the same category of software. I see no disagreement, how is GP "completely wrong"?

Edit: I'm wrong on my first reply, as pointed out here: https://news.ycombinator.com/item?id=46226602 LLVM is free software, and it is a confusion to equate copyleft and free software, though I still maintain that free and open source are very distinct concepts which refer to different categories of licenses. That contrast is better stated by RMS in the article on the subject above which I linked above. Original repl…

> LLVM is NOT free software because it is released under the Apache license, which is an open source license but not a free software license.

GNU disagrees with you: https://www.gnu.org/licenses/license-list.html

> Apache License, Version 2.0 - This is a free software license, compatible with version 3 of the GNU GPL.

Furthermore:

> Further it is not really a confusion to equate permissive licensing with open source as distinguished from copyleft and free software.

You are in disagreement with the FSF on this issue. "permissive" licenses also follow the Four Essential Freedoms, none of which require viral licensing.

Re: Rust in the kernel is no longer experimental

#757

Post by leadingthenet »

CursedSilicon wrote: post #614
iurbwdj wrote: post #394

Earlier quoted context omitted.

It involved large parts of the Rust community, and the famous Rust developer Hector Martin (with an alter ego of Asahi Lina, a female vtuber, which he appears irrationally embarrassed about), harassing others. Even Linus Torvalds called out Hector Martin. https://lkml.org/lkml/2025/2/6/1292 > On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote: > > If shaming on social media does not work, then tell me what does, becaus…

Is there any evidence "Asahi Lina" is Hector?

At this point I suspect anyone who even asks that question of concern trolling. The evidence is overwhelming.

Re: Rust in the kernel is no longer experimental

#758

Post by johncolanduoni »

maccard wrote: post #483
johncolanduoni wrote: post #103

Earlier quoted context omitted.

You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented. That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary arch…

How many of them are running Linux, and how many of them are running a modern kernel?

Almost none of them, but that doesn’t make them “places no one uses”, considering everyone who can see these words is looking at a device with a bunch of C firmware running on microcontrollers all over the place.

Re: Rust in the kernel is no longer experimental

#759

Post by uplifter »

steveklabnik wrote: post #755
uplifter wrote: post #751

Earlier quoted context omitted.

Edit: I'm wrong on my first reply, as pointed out here: https://news.ycombinator.com/item?id=46226602 LLVM is free software, and it is a confusion to equate copyleft and free software, though I still maintain that free and open source are very distinct concepts which refer to different categories of licenses. That contrast is better stated by RMS in the article on the subject above which I linked above. Original repl…

> LLVM is NOT free software because it is released under the Apache license, which is an open source license but not a free software license. GNU disagrees with you: https://www.gnu.org/licenses/license-list.html > Apache License, Version 2.0 - This is a free software license, compatible with version 3 of the GNU GPL. Furthermore: > Further it is not really a confusion to equate permissive licensing with open source…

I stand corrected! Thank you for the info.

The four essential freedoms[0] are good reading for the first principles of software freedom concept.

[0]https://en.wikipedia.org/wiki/The_Free_Software_Definition

Re: Rust in the kernel is no longer experimental

#760

Post by accelbred »

josephg wrote: post #741
accelbred wrote: post #606

Earlier quoted context omitted.

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…

You said above: > Also, a more Rust-friendly model would have incured higher memory costs. I'm not sure how modelling everything in a rust borrow checker friendly way would change anything here? Everything you're talking about doing in C could be done more or less exactly the same in rust. Arenas are slightly inconvenient in rust because the standard collection types bake in the assumption that they're working with t…

Arenas aren't the issue. Its objects with mixed lifetimes and mutability. I cant easily model the lifetimes of objects when there are cases like an instance where buffer memory reachable from the object has a different lifetime than maps/lists. Also these objects could be transively shared or mutable. In order to make a Rust friendly model, I'd have the tree be all shared or all mutable, and have all reachable memory have the same lifetime. This would often mean allocating the full tree into one arena. That is where the overhead comes from. Each arena would need enough memory to store the entire object; currently they can be smaller since they often only need to hold parts of objects, not the entire thing.
Post reply on HN