Smart pointers for the kernel

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 embedded person writing kernel drivers in slapped-together C than a Rustacian that complains about unsafe code and being an idiot about it. See [0] for detailed explanation.

People need to learn the niceness of safety and perfect execution is a continuum of tolerances and flimsy guarantees from unmarked silicon that could be made in US, but is most likely a knock off made in China that will fail in 1/3rd of the expected time and gives a false reading if you so much as look at it the wrong way.

[0] https://www.usenix.org/system/files/1311_05-08_mickens.pdf

You can do that in rust. Yes, you probably will have unsafe blocks. You can even write "C like" rust code that has a bunch of unsafe blocks but you'll benefit from better tooling. But maybe I misunderstand the article and there is somehow an implication that unsafe blocks are bad?

When I was doing some embedded development using rust it was actually a great experience, with hal and pac crates available already for a lot of hardware or easy to generate.

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.

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.

See, I read the parent post's point not as "abstractions are bad" but as "it's much better to be someone who doesn't need the abstraction, but chooses to use it". I have worked with a number of crappy embedded developers in my career. Somehow, the ones who are capable of going beneath the many levels of abstraction are always really, really good at their jobs.

So it's not that embedded Rust is bad. It's that developers who can't do their jobs without embedded Rust are usually very bad indeed. It's great when it's a choice. It's terrible when you lack the skills or perspective to work with what's under the hood.

Plenty of people writing rust are coming from that background. And a substantial part of the reason for wanting it in linux is that the slapped-together C in linux drivers is often awful, both in terms of understanding of the hardware and in terms of the quality of the software. Rust can at least help the poor quality of the latter not affect the security and stability of the kernel so much.

The problem starts when the abstraction fails and you have to dive deeper, but no one taught you how to dive, only swim with a head above the water level. Those who can dive can also swim, it doesn't work the other way round, though.

And who is to say that the people writing Rust are worse at swimming than you are?