rust?

Posted Feb 26, 2025 14:44 UTC (Wed) by wkudla (guest, #116550)
In reply to: rust? by amarao
Parent article: A change in maintenance for the kernel's DMA-mapping layer

I am equally baffled by this because it's just petty bordering on childish. Rust in no way impacted his work or required him to do anything. He just didn't like it so quit in a tantrum.

rust?

Posted Feb 26, 2025 15:55 UTC (Wed) by pizza (subscriber, #46) [Link] (26 responses)

> I am equally baffled by this because it's just petty bordering on childish. Rust in no way impacted his work or required him to do anything.

You are missing a critical point here -- Linus has effectively stripped Hellwig of his authority/power as a maintainer of a critical subsystem. Why would anyone want to continue to be officially responsible for something they do not have the authority/power to make decisions over?

> He just didn't like it so quit in a tantrum.

Stepping down quietly is the polar opposite of a tantrum.

rust?

Posted Feb 26, 2025 16:28 UTC (Wed) by garyvdm (subscriber, #82325) [Link] (9 responses)

> Linus has effectively stripped Hellwig of his authority/power as a maintainer of a critical subsystem.

Ah... no. That's not how I read things.

Linus wrote:
> You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it.
>
> But "ignore the Rust side" automatically also means that you don't have any *say* on the Rust side.
>
> You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".

Remember that the Rust DMA bindings being asked for merge sat *outside* the DMA subsystem.

Where is Linus say you no longer have authority/power over the DMA subsystem?

rust?

Posted Feb 26, 2025 20:39 UTC (Wed) by smurf (subscriber, #17840) [Link] (8 responses)

> Where is Linus say you no longer have authority/power over the DMA subsystem?

He doesn't. Mr Hellwig essentially wrote, "I won't work with the Rust people and I don't care about your Rust policy", Linus replied with "I don't care that you don't care", and Hellwig's reaction to that was not "OK let's see how things *actually* work out before I say 'I told you so'" but "OK fine then I quit".

He's fine to do that of course, nobody forces him to do anything, but the flip side is that nobody forces me (or anybody else of course) to have a particularly high opinion of somebody who chooses to deal with imaginary problems that way.

And yes they are imaginary problems at this point. They don't become non-imaginary unless and until there actually *is* a (technical) problem that needs maintainer interaction, and things have not progressed that far yet AFAIK.

rust?

Posted Feb 26, 2025 22:03 UTC (Wed) by jmalcolm (subscriber, #8876) [Link] (7 responses)

Nobody was forcing him to work with the Rust people.

He was demanding that they not exist, at least not officially, in the kernel.

He tried to say that they could not work with his code. Nobody was asking him to work with their code.

Linus did not have to strip him of authority OUTSIDE of dma. He never had any to begin with.

If he does not want to work on a project that allows Rust code, that is his choice. Let's call it what it is though.

rust?

Posted Feb 26, 2025 22:10 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> Nobody was forcing him to work with the Rust people.

30+ years of Linux history shows that maintainers _are_ forced to work with the in-tree users of their subsystems.

Sorry.

rust?

Posted Feb 27, 2025 0:14 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

That WAS the rule. If you break in-tree code you fix it.

But that was explicitly changed for Rust - if your C changes broke Rust, it was down to the Rust guys to fix it.

And as a maintainer of ANY subsystem, you need a clearly defined API. That's the problem here - the DMA code had (has) a contradictory API. Forget Rust, that's something that needs fixing.

The deal as it stands is that if your C changes break C, you're still expected to fix it. Sane programming demands that if you change an API you should document it. Leave Rust out of it, the deal is if you have an API, you should document it and then you can forget about Rust - it's their problem to follow your API.

Cheers,
Wol

rust?

Posted Feb 27, 2025 7:42 UTC (Thu) by Mook (subscriber, #71173) [Link] (1 responses)

I think the ultimate question comes down to: will Linus merge a pull request that breaks building the rust DMA bindings?

Down thread of this week's quotes of the week: https://lwn.net/ml/all/CAHk-=wjg1PJ81E23DB1QbvPBQ04wCf7mJ...

> The most common situation is that something doesn't build for me, [snip…]

> My build testing is trying to be wide-ranging in the sense that yes, I do an allmodconfig build on x86-64 [snip…]

rust?

Posted Feb 27, 2025 9:17 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

Theoretically yes according to the policy. In practice that's extremely unlikely to happen as it would be detected in linux-next.

rust?

Posted Feb 28, 2025 11:46 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Nobody was forcing him to work with the Rust people.

True. The alternative being quitting. Which he did.

rust?

Posted Feb 28, 2025 11:49 UTC (Fri) by amarao (guest, #87073) [Link] (1 responses)

There going to be the moment, when the same may happen to C people.

It's a very slippery slope, when you reject people based on their preferences of language, mascot and deity.

rust?

Posted Feb 28, 2025 12:17 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

> when the same may happen to C people.

It is happening to C people…

rust?

Posted Feb 26, 2025 16:30 UTC (Wed) by wkudla (guest, #116550) [Link] (15 responses)

> Why would anyone want to continue to be officially responsible for something they do not have the authority/power to make decisions over?

Could you expand on that? My understanding was that Hellwig would not be responsible for rust code in the slightest. He was opposing rust targeting his apis. But I might be missing something important here.

rust?

Posted Feb 26, 2025 16:57 UTC (Wed) by judas_iscariote (guest, #47386) [Link]

He is entirely right on stepping down because that will end up happening, complains WILL end in his plate, WILL make he waste time..maybe not now..not it will surely happen in the near future.

rust?

Posted Feb 26, 2025 17:28 UTC (Wed) by pizza (subscriber, #46) [Link] (13 responses)

> Could you expand on that? My understanding was that Hellwig would not be responsible for rust code in the slightest. He was opposing rust targeting his apis. But I might be missing something important here.

Maintainers have _always_ been responsible for all [1] in-tree users of their subsystems -- they change an API, all users need to be fixed up. Additionally, they're the point of contact of bug reports and other problems.

Saying "no, you're not responsible for _that_ class of in-tree users" directly contradicts longstanding mainline Linux policy, and leads to spider-man meme situations.

[1] And I do mean _all_. Even the "optional" [2] components such as every device driver.
[2] Rust is only "optional" until something you need is written in it. Such as a display driver for those extremely rare Arm Macs.

rust?

Posted Feb 26, 2025 17:33 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

Rust is not really going to be optional. That's not what the policy means, it only says that updating bindings and/or Rust drivers for API changes falls on the shoulders of Rust maintainers. *If* the C-side maintainers want the Rust maintainers to do the work and won't even entertain the idea of sharing with them a topic branch, the breakage will be handled in linux-next.

I expect that Rust will not break Linus's tree except in extremely rare cases that are more mistakes than policy, because the development process is already designed to allow and coordinate tree-wide changes (which aren't that frequent anyway).

rust?

Posted Feb 26, 2025 18:42 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link]

> Maintainers have _always_ been responsible for all [1] in-tree users of their subsystems -- they change an API, all users need to be fixed up.

That's not the rule for maintainers, that's the rule for everyone because we work in a monorepo.

Maintaining a critical subsystem cannot give you absolute veto power over the rest of the kernel, it has _never_ worked that way.

There's no absolute rules here, except for maybe - try to work with your fellow engineers, be reasonable, and keep the whole thing working. No one person's interests or wishes override everyone else's, we have to balance everyone's priorities.

And to keep the spider man memes going, with power comes responsibility.

rust?

Posted Feb 27, 2025 9:49 UTC (Thu) by amarao (guest, #87073) [Link] (10 responses)

> Maintainers have _always_ been responsible for all [1] in-tree users of their subsystems -- they change an API, all users need to be fixed up. Additionally, they're the point of contact of bug reports and other problems.

As far as I know the story, there is a condition for Rust code, that maintainer can break them and change thing without thinking about Rust problems, and Rust people will fix their code to match breaking changes. So, it's not a 'usual in-tree user'. But, perhaps, the mere existence of Rust code was unpleasant.

rust?

Posted Feb 27, 2025 11:00 UTC (Thu) by Wol (subscriber, #4433) [Link] (9 responses)

To be honest, the problem is probably that the existence of Rust now means that the *lack* *of* *documentation* has become a merge blocker.

If a C maintainer changes an API, it's now no longer enough to update all the (C) callers of that API, the guy now has to document the API as well!

Seriously? And they expect the lack of documentation to be acceptable?

Cheers,
Wol

rust?

Posted Feb 27, 2025 11:21 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (8 responses)

> Seriously? And they expect the lack of documentation to be acceptable?

How often has our dear editor remarked that some fancy new merged behavior of the kernel is "rigorously undocumented" (or along those lines)?

rust?

Posted Feb 27, 2025 11:54 UTC (Thu) by amarao (guest, #87073) [Link] (7 responses)

That the thing which surprise me about the kernel the most. Documentation.

Some things are just plainly not documented. And I'm not talking about sysctl.osbcure.mode, I'm talking about big things like nftables. There is a wiki, but the kernel itself (repo) literally have nothing about it. Not how to do it, not how to program it. There is just few mentioning about netfilter, and that's all.

rust?

Posted Feb 27, 2025 13:34 UTC (Thu) by daroc (editor, #160859) [Link] (6 responses)

For those readers who may be unaware: Jon is the official documentation maintainer for the kernel, alongside everything else he does. And he's very friendly. So if you were looking to help the kernel project, but feel uncomfortable writing kernel C code, you could consider helping to clean up and expand the documentation.

And, if you think you can do that documentation in the form of an LWN.net article of about 1500 words, we will even pay you for it. See the "Write for us" link in the sidebar. Lots of the kernel's official documentation links to LWN.net articles, so it's not without precedent.

rust?

Posted Feb 27, 2025 14:04 UTC (Thu) by amarao (guest, #87073) [Link] (5 responses)

That's we should do. I feel I can write a bit, but it quickly gets to the point if I understand it well or not. You need to be at least a senior level to understand code well enough to document existing code.

But we definitively should try. Better to have incomplete and jerky docs, than serene and concise "no docs".

rust?

Posted Feb 27, 2025 14:53 UTC (Thu) by Wol (subscriber, #4433) [Link] (4 responses)

Don't forget, writing good documentation is a skill. And good coders are often crap documenters.

Apologies for getting on my high horse here - but has anybody noticed what happened to kernel raid wiki? It was aimed at USERS - people running raid, people who didn't know what raid was, people who wanted to set up a system. It quite deliberately did NOT attempt to duplicate the official kernel documentation.

So someone came along, archived it with a big notice saying "this is obsolete, refer to the official kernel documentation if you need anything". WTF!!!

For the target readers of the wiki, the official kernel documentation is probably written in something worse than double dutch !!!

And this is a major problem with modern documentation - it usually completely ignores the user and is written BY experts, FOR experts. Which is why most user documentation is a case of the blind leading the blind. (My new TV is a case in point - it's a complicated computer, and the user documentation consists pretty much entirely of "plug the power lead here, the network cable there, and the aerial this other place". There's loads of fancy stuff we don't have a clue how to use!)

PLEASE KERNEL GUYS - *DON'T* piss off users who are trying to teach people how to USE your software. Without users, there's no point you writing it !!!

Cheers,

Wol

rust?

Posted Feb 28, 2025 8:48 UTC (Fri) by taladar (subscriber, #68407) [Link] (3 responses)

To be fair writing documentation for a beginner as an expert is genuinely hard since the thought processes can be entirely different and you don't even consciously think about many of the things other people might not know that you have known for decades.

However having expert documentation for experts would be a good first step at least to allow someone else with a different skill set to write documentation for users. Having no documentation at all requires both the skill set to read undocumented code (which is much harder than writing undocumented code) and the skill set to write good documentation in the same person.

rust?

Posted Feb 28, 2025 14:06 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Agreed. One strategy I use is to at least get my brain dump down somewhere as a seed. Then try to prod others to go through the steps of the process via the docs and to involve me in review of the results. Any missed steps (because they're "implicit" to me) get written down for posterity.

rust?

Posted Feb 28, 2025 15:44 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> However having expert documentation for experts would be a good first step at least to allow someone else with a different skill set to write documentation for users.

Actually no. From the user's PoV, (a) that documentation is probably written in double dutch, and (b) addresses completely the wrong problem, anyway. If I want to learn to be a chauffeur, why on earth do I want a detailed schematic of an Internal Combustion Engine? (Yes, knowing that schematic might be useful, but it's completely orthogonal to the problem at hand.)

The gap between the maker's understanding, and the user's understanding, of any product grows wider much faster than I suspect many of us here realise. A good maker is curious about what they're making. A user usually cares very little beyond "how do I get this to work" (because they don't have time for much more). Assuming the documentation will be cross-comprehensible between the two groups is asking for problems ...

Cheers,
Wol

rust?

Posted Feb 28, 2025 18:34 UTC (Fri) by draco (subscriber, #1792) [Link]

Umm, reread the quoted text again.

It's not saying that "expert documenting for experts, the end" = "user documentation, though of lower quality"

It's saying that "expert that's bad at user documentation documenting for experts that can't figure it out from raw code" leads to "experts that are good at user documentation creating decent user documentation" with higher probability than the alternative.

Now, if you're saying that documenting how it works instead of intended behavior for end users doesn't necessarily help describe the intended behavior, that's a fair statement, but I'd argue that if you don't have both, you don't have adequate expert documentation either.