Rust for Linux Workshop: The perils of pinning | Hacker News Reader

Rust for Linux Workshop: The perils of pinning

lwn.net

45 pointschmaynard12 comments

The intro may give an impression that Rust has less control about moving values than C, but that's not accurate. The problem is that both languages behave exactly the same: they can pass and assign structs by value, which changes their address.

In C any problems caused by this are "solved" just by telling programmers not to do that. In Rust that's not good enough — safety guarantees are supposed to catch such violations, so the goal is to automatically and robustly prevent incorrect struct moves. Rust already makes that safe by default when using the borrow checker, but it doesn't have a nice built-in mechanism for preventing moves of non-borrowed structs.

Pretty much. In Rust you have to convince compiler what you're doing makes sense or tell compiler to fuck off, in C it's pretty much "it's your funeral, whatever dude"

In Rust you have to create and initialize an object on the stack and then move it to the heap. This is not necessary in C.

The usual safe way is to do that, and count on LLVM to eliminate the copy. However, Rust also has a MaybeUninit wrapper type for allocating uninitialized memory wherever you want and writing to it directly.

    struct list_head {
        struct list_head *next, *prev;
    };

I'd done a few Rust tutorials before I thought to myself Hmmm, what's something basic I can try making in Rust? I know, a linked list. Oh boy, was that a schooling...

Haha, yep. Now for added challenge make it doubly linked to run into ownership issues (if you didn't already). I do like the language, but damn it forces you think carefully what you're doing.

The Linux kernel uses intrusive data structures to avoid a superfluous memory allocation and cache-friendliness. There's also an intrusive Red-black tree and Radix tree implementation in the kernel.

A linked list is not cache friendly unless the nodes are allocated mostly nearby. But if one can ensure such allocation, then why not to use an array or at least a list of small arrays?

The kernel uses struct embedding for puting structs into lists. You can't do that with an array.

To anyone wondering what kind of schooling exactly it is: https://rust-unofficial.github.io/too-many-lists/

relevant video by fasterthanlime: "Self-referential structs (in Rust)" https://www.youtube.com/watch?v=xNrglKGi-7o

Two questions:

1. Does Rust have an idiomatic way of providing a similar data structure that also limits allocations and maintains cache-friendliness?

2. How pervasive are these intrusive linked lists in the kernel code, especially in boundaries between major systems? Would it be possible to create seams in the kernel code that pass structures with idiomatic Rust equivalents, then use those as a guide to moving Rust into the kernel without contorting it to work with C data structures that are hard to represent?

Reply on news.ycombinator.com