Hacker News Reader

Comment by jeroenhd | Hacker News Reader

I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel.

It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.

This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.

That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.

View on HN

The DMA subsystem maintainer has some reasons: at this time you can disable all rust drivers when building the Linux kernel but you cannot disable rust wrappers to C language APIs. So if you need to change for example the DMA APIs, you also need to fix the rust wrapper before submitting the C patches otherwise you cannot even build a C only kernel.

I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.

A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.

It’s a little bit more nuanced than this. Your parent commenter is wrong, by the way.

Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.

This was illustrated with an example in that email thread.

I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.

> However, the discussion is over

It's not. Certainly not until Linus says it is.

> Rust has been accepted into the kernel.

As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.

> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.

Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.

Luckily, the kernel seems to be doing fine.

The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists.

Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.

how forkable is the whole thing? I mean, it is several decades of code but...

It's not.

What?! Almost every major server and desktop Linux distribution ships a kernel full of patches, which are absolutely forks. That’s before we start getting into the crazy town of the embedded world. Clearly the software can be forked. The question is whether the community can - and that is yet to be seen.

All those "forks" are dependent on regularly rebasing their patch sets on top of mainline (or they never get updated and lose what semblance of support they had once the SoC they were made for reaches EoL), so they're pretty much irrelevant to this conversation. We have seen no indication that it's feasible for anyone to hard-fork the kernel and continue development in a way that's independent from what we today call "mainline".

its totally forkable. in fact its totally possible to write a 99% workalike.

the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.

Also it's, y'know, written in C.

I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.

Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.

C programmers are getting rare...

Why are you projecting your own feelings onto others?

There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.

they don't avoid it cause the hostility , they avoid it case we live in this high level era , where nobody knows where code runs or how it runs.

> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things.

Both sides of the argument are kernel developers here, though.

Well, one side just quit.

And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.

I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.

The person who quit was not the author of the patch, or a member of Rust for Linux.

So they stirred a whole lot of drama for not much, potentially harming R4L.

I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.

The person who quit wrote the Linux graphics driver for Apple M-series GPUs in Rust.

edit: I may have gotten some things confused, please see below

No. The person who quit upstream kernel work is Marcan, the head of the Asahi Linux project. The person who developed the kernel driver for M-series GPUs is Lina.

Not sure why my comment was flagged, but marcan is Asahi Lina. There is demonstrable proof in threads all over this comment section.

No, the entirety of the Rust for Linux kernel development community didn't just quit. One guy quit. There are plenty of other kernel developers who are trying to push Rust 4 Linux forwards and make it viable for more kinds of drivers.

Reply on news.ycombinator.com