←back to thread

364 points Klasiaster | 4 comments | | HN request time: 0.732s | source
Show context
akira2501 ◴[] No.41851912[source]
I personally dislike rust, but I love kernels, and so I'll always check these projects out.

This is one of the nicer ones.

It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code).

Not bad!

replies(2): >>41852794 #>>41855386 #
wg0 ◴[] No.41855386[source]
Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around.

But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?

replies(5): >>41855987 #>>41855995 #>>41856204 #>>41856306 #>>41856588 #
1. junon ◴[] No.41856588[source]
Context: I'm writing a novel kernel in Rust.

Lifetimes aren't bad, the learning curve is admittedly a bit high. Post-v1 rust significantly reduced the number of places you need them and a recent update allows you to elide them even more if memory serves.

Arc isn't any different than other languages, not sure what you're referring to by ref but a reference is just a pointer with added semantic guarantees, and Pin isn't necessary unless you're doing async (not a single Pin shows up in the kernel thus far and I can't imagine why I'd have one going forward).

replies(1): >>41858618 #
2. mcherm ◴[] No.41858618[source]
Would you not want to use Pin when sharing memory with a driver or extension written in a different language (eg: C)?
replies(2): >>41861219 #>>41868083 #
3. bombela ◴[] No.41861219[source]
Pin is a pure compile time abstraction for a single problem: memory safety of self referential struct.

Pin leverages the type system to expose to the programmer receiving a pointer to a Pin'ned object, that this object has some pointer on itself (a self referencial struct). You better be mindful not to move this object to a different memory location unless you know for sure that it is safe to do so. The Pin abstraction makes it harder to forget; and easier to notice during code review; by forcing you to use the keyword unsafe for any operations on the pinned object that could move it around.

In C, there is no such way to warn the programmer besides documentation. It is up to the programmer to be very careful.

4. junon ◴[] No.41868083[source]
Nah not really. Pin is for self-refefential data typically. It's compile time only so that information would get lost in C anyway, and there's no way to distinguish that data at runtime.

The kernel is doing so much anyway with memory maps and flipping in / out pages for scheduling and context switching that Pin doesn't add any value in such cases anyway.

It was also specifically built for async rust. I've never personally seen it in the wild in any other context.