Hacker News Reader

> It needs a layer of quasi-stable well documented subsystem APIs

I think the Rust developers weren't even asking for that. They just want the C developers to sign up to some semantics. But the C developers know the function interface has evolved to be merely functional: it works, but with few invariants, riddled with caveats and few cross-function guarantees. It can't be hoisted into meaningful semantics, no less a type system, particularly across 10 filesystem API's.

Rust developers should focus on drivers in subsystems with stable API's, instead of trying to stabilize what decades of work has failed to.

Of course it has semantics. Whether someone knows all of them is a different matter. But whether you use rust or c you have to know the contract to be able to write correct code. The only reason the kernel devs got away with such sloppiness is because c is the ultimate 'I do what you tell me to boss" language.

And yet, Rust is the exact opposite. Why try to make the two meet? The argument for Rust in the kernel over memory safety can be remediated by better memory safety tools for C can't it? (Not that the Linux kernel project doesn't have any already.)

Why not devote the time to writing a better memory safety tool for the Linux kernel (or C in general) rather than keep trying to force two disparate cultures and ideologies to meet in some fantasy middle?

ThePrimeagen actually had an interesting opinion on this recently too, worth a watch: https://www.youtube.com/watch?v=62oTu9hjxL4

Rust has the very strong pro of already existing. If those tools existed, I’m sure the conversation would be quite different.

It’s also not just about memory safety. Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs, for example.

> Rust has the very strong pro of already existing

But not in the Linux kernel. Any new effort will be greenfield, why spend the last two years and many more rallying around an entirely different programming language instead of writing a novel tool?

> Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs

Do you have any examples here?

> But not in the Linux kernel.

Sure, it is still an experiment, but that's irrelevant: your theoretical "make C memory safe" tooling does not exist and does not exist in the kernel.

> instead of writing a novel tool?

Do you have a proposed design for the novel tool? Many have tried, nobody has succeeded.

> Do you have any examples here?

From the article:

> Kroah-Hartman said that it could eliminate entire classes of bugs in the kernel.

He's said similar things elsewhere: https://social.kernel.org/notice/AlxbVeMxyJNsLoNa6q

There are no decent memory safety tools for C. Could they be theoretically created? Perhaps, I doubt it considering the amount of money flowing in this industry. To solve it you really have to design a new language. Which is exactly what happened it's called Rust.

Kernel devs should just put on their big boy pants and go with the times. C is simply not the right tool for the job anymore for a lot/most kernel work.

Why, because of the cost of exploited vulnerabilities and critical systems failures that could have been avoided.

For those curious, this is the link[0] to the filesystems talk with the relevant timestamp. A bit more was discussed in this[1] article as well about Wedson Almeida Filho leaving.

[0]: https://youtu.be/WiPp9YEBV0Q?t=1529

[1]: https://lwn.net/Articles/987635/

Why do we need quasi-stable anything within the kernel? Wouldn't a much better long-term solution be changing the rule to "break whatever APIs you want, but you have to fix all of the in-tree Rust uses too"?

The problem is that some high-profile people who want to preserve their right to "break whatever", do not want to shoulder responsibility of fixing Rust code which depends on the broken stuff. Even worse, they even do not want to explain and document semantics of existing APIs (sic)! See the video linked in the sibling comment.

Speaking more broadly, freely breaking stuff in large projects is dangerous, since fixing stuff may require a more specialized expertise and knowledge, e.g. being well-versed in Rust safety rules, knowing some obscure information about hardware behavior, or being aware about some tricky invariant which must be preserved by the code. This is why changes in API boundaries often require synchronization between different teams.

At least Ted Tso has clarified his position greatly from what initially read as “I refuse to learn rust”. Instead yes asking for a guide to help him understand the Rust:

> There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn.

This is heartening to read for sure.

> since fixing stuff may require a more specialized expertise and knowledge

That's why sign-offs from reviewers are "required", no?

It seems the correct mentality to encourage people to do hack on the kernel, show that things are possible, they are "working on my machine", and then ... yeah, they will need to go through the usually length process of getting it merged.

But starting with "synchronization between different teams" usually gets shrugs and "let's get back to it soon"-s.

One of the advantage of big monorepos (and Linux really is just one big "monorepo") is that you can change $whatever as long as you also fix everything that depends on that.

Sometimes this is just simple stuff, like adding a function argument, changing a type, or something like that.

"Break whatever" is a bit of a crude way of putting it, but yeah, it's definitely an advantage IMHO. Not just for the final patch, but also prototyping, experimenting, showing ideas, etc.