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

Smart pointers for the kernel

lwn.net

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Smart pointers for the kernel

#41

Post by eru »

jendjdndn wrote: post #31
stonethrowaway wrote: post #14

Anyone who wants to do kernel-level development should first do Embedded hardware/software interfacing. No RTOS, plain “Embedded C”, with some bit banging and dealing with voltage spikesc transients and people doing stupid shit to hardware (yes, really) and other things. Know the memory map and recite it from memory. Some might think I’m joking or being facetious - no, I’m pretty serious actually. I’d rather have an…

You sound a lot like "kids these days!" What applicable skills would someone writing a kernel driver gain from reciting a memory map? Abstractions exist for a reason. The skill is in creating useful an performant abstractions.

> You sound a lot like "kids these days!"

Exactly! Kids like stonethrowaway with their C. Real engineers write their compilers in assembly.

(Less snarky, why stop at C, and not complain about even lower level stuff?)

Re: Smart pointers for the kernel

#42

Post by stonethrowaway »

eru wrote: post #41
jendjdndn wrote: post #31

Earlier quoted context omitted.

You sound a lot like "kids these days!" What applicable skills would someone writing a kernel driver gain from reciting a memory map? Abstractions exist for a reason. The skill is in creating useful an performant abstractions.

> You sound a lot like "kids these days!" Exactly! Kids like stonethrowaway with their C. Real engineers write their compilers in assembly. (Less snarky, why stop at C, and not complain about even lower level stuff?)

> Real engineers write their compilers in assembly.

Not sure where this misconception comes from. The engineering department mostly relies on Verilog twiddling, shoddy Spice models, debugging prototype boards with poorly crimped jumper wires, charged capacitors scattered around with no adults in the room, and freshly minted junior EEs who forget spice models and Verilog hacks aren’t the real thing.

You have the wrong department. Software development is down the hall to the left. Those folks down there don’t even have an engineering degree.

Re: Smart pointers for the kernel

#43

Post by mort96 »

foundry27 wrote: post #3
smodo wrote: post #2

I’m not very well versed in kernel development. But I am a Rust dev and have observed the discussion about Rust in Linux with interest… Having said that, this part of the article has me baffled: >> implementing these features for a smart-pointer type with a malicious or broken Deref (the trait that lets a programmer dereference a value) implementation could break the guarantees Rust relies on to determine when object…

Rust’s whole premise of guaranteed memory safety through compiletime checks has always been undermined when confronted with the reality that certain foundational operations must still be implemented using unsafe. Inevitably folks concede that lower level libraries will have these unsafe blocks and still expect higher level code to trust them, and at that point we’ve essentially recreated the core paradigm of C: trust…

It is literally impossible to build systems where you never at any point trust that underlying systems work correctly. This is a boring and uninformative criticism. It is the case for every language ever invented.

Re: Smart pointers for the kernel

#44

Post by weinzierl »

kelnos wrote: post #8
foundry27 wrote: post #3

Earlier quoted context omitted.

Rust’s whole premise of guaranteed memory safety through compiletime checks has always been undermined when confronted with the reality that certain foundational operations must still be implemented using unsafe. Inevitably folks concede that lower level libraries will have these unsafe blocks and still expect higher level code to trust them, and at that point we’ve essentially recreated the core paradigm of C: trust…

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

"For projects that do need unsafe, that unsafe code can be cordoned off into a corner, where it can be made as small as possible, and can be audited. The rest of the code base is just as safe as one with no unsafe at all. This is also very useful!"

Exactly this, and very well put!

I'd just like to add one small but important detail. It's one of the things that is so obvious to one group that they rarely even mention it, but at the same time so obscure to the others that they are completely oblivious to it.

While the unsafe code is cordoned off into a corner its effects are not. A bug in an unsafe block in one part of your program can trigger an outcome in a completely different and safe part of your program, that normally safe Rust should prevent.

To put it more metaphorically, Rust restricts the places where bombs can be placed, it does not limit the blast radius in case a bomb goes off.

This is still huge progress compared to C/C++, where the bombs can and usually are everywhere and trying to write it safely feels a lot like playing minesweeper.

Re: Smart pointers for the kernel

#45

Post by im3w1l »

Rusky wrote: post #20
foundry27 wrote: post #3

Earlier quoted context omitted.

Rust’s whole premise of guaranteed memory safety through compiletime checks has always been undermined when confronted with the reality that certain foundational operations must still be implemented using unsafe. Inevitably folks concede that lower level libraries will have these unsafe blocks and still expect higher level code to trust them, and at that point we’ve essentially recreated the core paradigm of C: trust…

It's not the same unwritten social contract: in Rust even the unsafe code has the same stricter type signatures as the safe code, so there is a formal way to judge which part of the program is at fault when the contract is broken. You might say the contract is now written. :-) In C, the type system does not express things like pointer validity, so you have to consider the system as a whole every time something goes w…

> In Rust, because the type system is sound

Unfortunately, it's not. Now I do think it will be eventually fixed, but given how long it has taken it must be thorny. https://github.com/rust-lang/rust/issues/25860

Re: Smart pointers for the kernel

#46

Post by acbits »

brenns10 wrote: post #26
acbits wrote: post #12

https://github.com/acbits/reftrack-plugin I wrote this GCC plugin for this exact reason. Let's see whether the kernel team is interested in adopting it.

I searched lore.kernel.org and couldn't find any postings that propose using this in the kernel. I'd encourage you to share a proposal, otherwise the "kernel team" will never be interested, because they'll never hear of it.

I will send it again. It probably got lost in the high traffic volume of LKML last year.

Re: Smart pointers for the kernel

#47

Post by rocqua »

smodo wrote: post #2

I’m not very well versed in kernel development. But I am a Rust dev and have observed the discussion about Rust in Linux with interest… Having said that, this part of the article has me baffled: >> implementing these features for a smart-pointer type with a malicious or broken Deref (the trait that lets a programmer dereference a value) implementation could break the guarantees Rust relies on to determine when object…

Rust is all about ring-fencing the scary parts in unsafe. A rust program that doesn't use unsafe, and only uses dependencies that are sound with respect to unsafe, is guaranteed to be fine. And it is very easy to write code without using unsafe. Unlike C, where code style that is guaranteed to be memory safe is nigh impossible.

The difficult bit with Rust is still the sound use of unsafe, but it is quite feasible to do that by hand. It does, sadly, require looking at the entire module that contains the unsafe code.

Re: Smart pointers for the kernel

#48

Post by I_AM_A_SMURF »

GolDDranks wrote: post #24
foundry27 wrote: post #19

Earlier quoted context omitted.

I’ll propose that most Rust projects that do useful work (in the potential energy sense?) depend on unsafe code, and it’s likely going to be found in the codebases of their dependencies and transitive dependencies. But I agree with almost all of what you’re saying about C and Rust; I work on a C operating system professionally, and I know those same pain points intimately. I program in Rust for fun, and it’s great to…

I’ll propose that ALL Rust projects that do useful work depend on unsafe code. If one claims otherwise, I say they have no understanding of Rust. But also, if one helds that against Rust's value promise, I, again, say that they have no understanding of Rust.

It's definitely all of them. Even HashMap uses unsafe.

Re: Smart pointers for the kernel

#49

Post by eru »

stonethrowaway wrote: post #42
eru wrote: post #41

Earlier quoted context omitted.

> You sound a lot like "kids these days!" Exactly! Kids like stonethrowaway with their C. Real engineers write their compilers in assembly. (Less snarky, why stop at C, and not complain about even lower level stuff?)

> Real engineers write their compilers in assembly. Not sure where this misconception comes from. The engineering department mostly relies on Verilog twiddling, shoddy Spice models, debugging prototype boards with poorly crimped jumper wires, charged capacitors scattered around with no adults in the room, and freshly minted junior EEs who forget spice models and Verilog hacks aren’t the real thing. You have the wrong…

In any case, you might like https://docs.rust-embedded.org/book/

I've recently done a bit of work on Rust in something like embedded systems. Only instead of real hardware, we are running our software on Zero Knowledge VMs, ie on math.

Re: Smart pointers for the kernel

#50

Post by thayne »

dzaima wrote: post #9
kelnos wrote: post #8

Earlier quoted context omitted.

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

nit - Rust does allow memory leaks in safe code. https://doc.rust-lang.org/std/mem/fn.forget.html#safety

It's also possible to leak memory in languages with tracing garbage collection, just create a data structure that holds strong references to objects that are no longer needed, which commonly happens when using something like a HashMap as a cache without any kind of expiration.
Post reply on HN