Rambling

Posted Jan 30, 2025 20:00 UTC (Thu) by Poliorcetics (subscriber, #165001)
Parent article: Resistance to Rust abstractions for DMA mapping

I find those exchanges sad to read.

One guy is:

- Blocking abstractions in his domain because he only wants C, which I don’t agree with but ok
- But also blocking other people offering to maintain the not C outside of his domain ?

That entire thread is a sad example of open source because one person feels like ruining it for everyone else.

Rambling

Posted Jan 30, 2025 20:49 UTC (Thu) by tesarik (subscriber, #52705) [Link] (67 responses)

Be careful with judgment, because you may also view it differently.

One guy (who already is overloaded) is not enthusiastic about adding yet another constraint to his work. Because what really happens if a change in the DMA API happens to break Rust bindings? It's not unreasonable to expect that such a pull request will be rejected or at least delayed. Which may seem like a small annoyance to you, but does Christopher still have enough spare energy to cope even with small annoyances? To me it looks that he does not even have the energy to provide a thorough explanation of his reaction…

Rambling

Posted Jan 30, 2025 20:58 UTC (Thu) by mb (subscriber, #50428) [Link] (3 responses)

So you have problem A (overloaded maintainers) and compensate it by causing problem B (causing more problems for Rust people)?
Doesn't make sense to me.

Especially as

>It's not unreasonable to expect that such a pull request will be rejected or at least delayed.

it is currently policy that Rust code may break at any time and the C-side maintainers are free to ignore that.

Rambling

Posted Jan 31, 2025 10:07 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

I don't think the problem of overloaded maintainers is helped by making them even more overloaded.

Rambling

Posted Jan 31, 2025 13:12 UTC (Fri) by dralley (subscriber, #143766) [Link]

He outright refused to take on a second maintainer to handle the Rust stuff when offered.

Rambling

Posted Jan 31, 2025 13:41 UTC (Fri) by dberlin (subscriber, #24694) [Link]

1. They are free to ignore it, so not sure how much burden that really is. I agree in principle that "just ignore it" is not zero overhead, but it's very very low overhead.

If you are so burdened that you can't handle this overhead, one option is to add another maintainer.

which leads to:

2. They explicitly offered to maintain it, and help with maintenance in general, which was also refused

These are not randos, either, these are people who have contributed plenty to the kernel, and so this isn't like some random person coming in and offering to help maintain things.

Rambling

Posted Jan 30, 2025 21:03 UTC (Thu) by smurf (subscriber, #17840) [Link] (28 responses)

Well, if he doesn't even have the capacity for that, it's well past time for distributing the work onto a couple more shoulders.

Anyway. Frankly I don't understand his objection. if he doesn't want Rust he should simply disable it in his builds, ignore any errors produced by it, and let others deal with the fallout. That's a strict improvement to the current state of things.

There already is a whole class of machines out there (Apple's ARM-based laptops) which basically require Rust, and there's certainly nobody stepping up to rewrite the whole effort in C just to please the anti-Rust crowd.

The alternative is to fork Linux, then spend the next 20 years putting the pieces back together, the way the Realtime Linux people did. I seriously doubt that this would be in anybody's best interest …

Rambling

Posted Jan 31, 2025 0:45 UTC (Fri) by cloehle (subscriber, #128160) [Link] (27 responses)

>There already is a whole class of machines out there (Apple's ARM-based laptops) which basically require Rust, and there's certainly nobody stepping up to rewrite the whole effort in C just to please the anti-Rust crowd.

Unless I've missed something that isn't upstream though?
You can rustify the entire tree downstream and nobody can stop you, so what's your point?

Rambling

Posted Jan 31, 2025 0:51 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (26 responses)

I think the point is that carrying patches out of tree, that are well tested, fully GPL-compliant, etc., is asinine. Yes, it is expected that the patch review process does a certain amount of quality control, but that does not mean rejecting any and all patches that pertain to some politically-disfavored technology.

Rambling

Posted Jan 31, 2025 10:12 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (25 responses)

He's rejecting more work for himself. How is this so hard for you guys to understand?

What would you say if your boss said: "from now on you work 12h a day. Forever. Same salary"?

That's what's happening here (the hour estimation is made up, but it's greater than before).

Can you honestly say you'd be like "uh, sure, no prob"?

Rambling

Posted Jan 31, 2025 10:58 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

I can understand him not wanting any more work himself. BUT.

Let's say he was asked to go from 8 to 12 hours a day. Yes I know that's a lot - 50%.

However, his refusal means his boss now has to hire THREE full time guys to cope with the extra work he's caused.

There's pros and cons both ways - "I'm overloaded I don't want any more work" is perfectly okay. But when the boss is saying "hey these changes will take work OFF you (AND US)", then that refusal is long-term counter-productive.

The problem is, as Brookes observed, "throwing extra man-power at a project only makes it later". It's a "how do you square the circle" problem - fixing pain in the long term is only possible by increasing it in the short term.

And of course the real tragedy is that it's Christoph who's being going through a lot of other people's subsystems, spraying patches everywhere, precisely to do the exact same sort of cleanup that Rust does when it rationalises APIs!

Cheers,
Wol

Rambling

Posted Jan 31, 2025 15:45 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (1 responses)

Linus isn't his boss… so the dynamic is not quite as you describe it I think.

Rambling

Posted Feb 12, 2025 20:50 UTC (Wed) by jmalcolm (subscriber, #8876) [Link]

You are the one that introduced the "boss" concept into the mix. Replace "Linus" with "community" or "LKML" or some other concept that you prefer.

To extend the thought experiment though, without getting into a long debate over the politics of the kernel, let me ask you a question. Can Linus "fire" a kernel maintainer? Because, pragmatically speaking, I think the answer is "yes".

Linus has ultimate authority over what code gets merged into Linux. That this is a fact should not be controversial. That is, he can decide who to accept patches from. He can provide public guidance to others as to who he will accept patches from and what sub-systems he will accept those patches from. If Linus can remove a maintainer from their job and replace them with somebody else, I think that saying that Linus can "fire" a maintainer is a reasonable simplification of language.

For the purposes of this conversation, I think we can agree that calling Linus "the boss" is a similar simplification of language. He has exactly the same attributes as my boss does in terms of how much power my boss has in forcing me to align with his views. Historically, Linus has wielded that power and done so quite effectively. Pretending that he has not or cannot is not an argument in good faith.

Extra work?

Posted Jan 31, 2025 10:59 UTC (Fri) by gioele (subscriber, #61675) [Link] (3 responses)

> He's rejecting more work for himself. How is this so hard for you guys to understand?

What extra work does this patch (and similar ones) impose on the maintainer?

(Sincere question from an external observer.)

That patch adds (what amounts to) a new client of one of the APIs that the maintainer manages, with the additional explicit reassurance that the API is free to evolve in any way, and the patch submitter will bear the costs of adapting their client to the new API. No code in the API or in the subsystem managed by the maintainer is or will be changed.

The only work for the maintainer is asked to do is to do a final check to ensure that the patch submitter got the finer details of the API correct (the patch was already on its 8th revision, so most of the checks have already been done by other developers). Answering such a request from client of your API does not count as "more work", does it?

(Please correct me if I got any of these details wrong.)

Extra work?

Posted Jan 31, 2025 15:47 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

In theory you're 100% right.

But in practice he can't really change API and break Rust and leave it at that. The whole change will be held back for release, so in practice he can't do it.

Extra work?

Posted Jan 31, 2025 18:09 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

linux-next exists for that reason. Such breaking change would be noticed quickly.

Extra work?

Posted Feb 5, 2025 5:23 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

Eh?

Code, not maintained by him, breaks, and holds up a release.

This really shouldn't hold up anything on his end at all.

If Linus, who is responsible for releases, complains, that makes sense to me. But not Hellwig.

Per the article, he said he is blocking it because he doesn't want a multi-language kernel. We should take him at his word.

Rambling

Posted Jan 31, 2025 13:16 UTC (Fri) by ms-tg (subscriber, #89231) [Link] (2 responses)

Interesting! My reading of the article, specifically that the Rust code will live outside the DMA project and be maintained by others, makes this comment confusing.

Can you dive a click deeper on the extra work that you are seeing being asked or the DMA maintainer?

Rambling

Posted Jan 31, 2025 15:57 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (1 responses)

Historically internal kernel APIs haven't been "fixed" like the external ones are (or claim to be, but really aren't).

So normally changing an API involves also fixing all the places where that API is called. Doesn't matter if they aren't in the same subsystem (and DMA is used by a lot of hardware).

So having Rust depend on that API means that to change it, the Rust code must be fixed as well.

The original idea was that one could just not learn Rust and let the build fail. But a kernel that doesn't build won't be released, so an eventual API change will be rejected if it doesn't fix also the Rust code, or there isn't enough time to fix it before the next release.

Plus, I don't know where he works at, but his actual boss might be unwilling to pay him to learn Rust instead of doing his regular job. And if he's not paid to do it, I'm not keen on thinking that it'd be ok to force him to do it anyway because a crowd has decided so.

Of course he can be ignored, but such things create bad blood and every once in a while it's enough to make people quit.

Someone pointed out that even if he quits, nobody cares. But kernel maintainers aren't an abundant resource I think.

Anyway having contributed to a project with Linus Torvalds myself, I would do it again only if I'm being paid to do it. There's no enjoyment in it and I don't have the hobby to make myself miserable on purpose.

Rambling

Posted Jan 31, 2025 16:28 UTC (Fri) by dralley (subscriber, #143766) [Link]

Nobody is asking him to learn Rust. All Rust maintenance can be handled by the RfL maintainers, with minimum input from him pertaining only to the details of the C APIs which Rust is wrapping.

Rambling

Posted Jan 31, 2025 13:42 UTC (Fri) by dberlin (subscriber, #24694) [Link] (6 responses)

"He's rejecting more work for himself. How is this so hard for you guys to understand?"

Actually, no, they offered to maintain it separately as well, and he nacked that too!

Rambling

Posted Jan 31, 2025 16:22 UTC (Fri) by tesarik (subscriber, #52705) [Link] (5 responses)

This is not exactly how I read it. Sure, they offered to maintain Rust bindings for the dma coherent allocator. But if a change in the C code happens to break Rust users, then somebody will eventually bisect the regression to that change and complain to the iommu@ ML. Does somebody volunteer to triage all reports?

Now, I don't think Christoph is right. If nothing else, he can't simply nak the patch series like he did. OTOH it doesn't really help if he gets a lot of heat here. Can we try to be constructive?

Rambling

Posted Feb 4, 2025 8:42 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

> But if a change in the C code happens to break Rust users, then somebody will eventually bisect the regression to that change and complain to the iommu@ ML. Does somebody volunteer to triage all reports?

I've triaged a gazillion of bug reports in my life and I really wish I had many more like "bisected commit X breaks compilation of file Y". I could have taken a lot more vacation.

Rambling

Posted Feb 4, 2025 20:20 UTC (Tue) by tesarik (subscriber, #52705) [Link] (3 responses)

> bisected commit X breaks compilation of file Y

That's totally not what I had in mind. A bisected commit X makes a subtle change to the semantic of the DMA API, and that breaks some drivers which use the Rust abstraction under certain not-so-common conditions. To fix them, the Rust abstraction must reflect the subtle change. That's the kind of thing I have in mind.

Rambling

Posted Feb 5, 2025 1:31 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

Good point, API breakages do not all show up at compilation time. On the other hand, these "pure semantic" changes are pretty rare. They're especially rare because... they suck and are best avoided. I mean who enjoys subtle search/replace (obfuscated by a few layers of C macros for good measure) when you can ask the compiler to go and not miss any in-tree API user instead? For that reason, it's typical to make sure that old code stops compiling even when it still could even after a semantic change.

This has been true with and without Rust.

In fact, if you want to be evil with out-of-tree code you can even go like this when changing an API:
- Force some "unnecessary" compilation error together with your desired semantic change
- Leverage that to let the compiler find all the spots that need a change. Make that change.
- Revert the unnecessary compilation error but keep the semantic change.

"Good" job: you just cost days or even weeks of debugging to out-of-tree users. As you had in mind.

BTW this technique of "breaking stuff for discovery" is very useful in general, for instance it's practically mandatory when hacking build systems; otherwise you always end up wasting hours editing something (e.g. CFLAGS...) in the wrong place.

Temporarily breaking stuff is also necessary to "test test coverage". I digress sorry.

PS: I've never used Coccinelle but it looks like it could play a role here.

Rambling

Posted Feb 5, 2025 1:38 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)

> (obfuscated by a few layers of C macros for good measure)
> [...]
> BTW this technique of "breaking stuff for discovery" is very useful in general, ...

Meant to say this and forgot sorry: I've temporarily and locally broken code many times just to trick the compiler into expanding a complex set of macros stacked on top of each other. Nothing I know comes close.

Who knows the code best? The compiler of course. So it must be relentlessly interrogated until it spills the beans.

Rambling

Posted Feb 5, 2025 17:33 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

It may know "what the code" as it exists, but it knows nothing of "why the code" which is also very important when making changes.

Rambling

Posted Feb 1, 2025 10:43 UTC (Sat) by intelfx (subscriber, #130118) [Link] (3 responses)

> He's rejecting more work for himself. How is this so hard for you guys to understand?
> What would you say if your boss said: "from now on you work 12h a day. Forever. Same salary"?
> That's what's happening here (the hour estimation is made up, but it's greater than before).
> Can you honestly say you'd be like "uh, sure, no prob"?

This is a cute analogy, but it doesn't work that way.

As you might know, the Linux kernel is a project with distributed governance. This means that there's not a single entity that fully controls the amount of work required of participants. Sometimes, the amount of this work changes, and that's part of the deal.

Consider, for example, the time when the BKL was removed. I'm absolutely sure that this development has increased the amount of effort and knowledge required of core maintainers by some orders of magnitude. However, if someone had come out with a veto on the BKL removal, citing "more work for himself" as reasoning, I'm 100% sure this would never fly as an argument.

Same thing here. If you, as a maintainer, recognize that something increases your workload past the point of sustainability, you go to your employer and say: "This new development, which is not under my control, requires more manpower to execute my duties than I can provide. You need to hire another engineer." Or, if there's no employer, you go to the mailing lists and do the same. Either the funding appears (in the form of someone else hiring another engineer), or it doesn't, and the project deals with this some other way.

Yes, this would mean that you lose your "fiefdom" and suddenly find yourself in need to cooperate with someone else. But that's an ego problem, not a technical problem.

Rambling

Posted Feb 1, 2025 10:59 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (2 responses)

I think you don't understand that people aren't slaves. They can quit whenever they want.

Rambling

Posted Feb 1, 2025 11:07 UTC (Sat) by intelfx (subscriber, #130118) [Link]

I literally just said that quitting is one of the correct responses.

Rambling

Posted Feb 1, 2025 15:21 UTC (Sat) by Wol (subscriber, #4433) [Link]

The problem is when the "fief chief" drives EVERYONE ELSE into quitting because they can't cope with his intransigence ... (or the extra work dumped on THEM in consequence ...)

It's not JUST the extra work "being dumped" on Christoph. It's all the extra work being dumped on EVERYONE ELSE to work round his intransigence.

Cheers,
Wol

Rambling

Posted Feb 12, 2025 20:36 UTC (Wed) by jmalcolm (subscriber, #8876) [Link] (3 responses)

If you are going to accuse people of not understanding, you should make sure you understand things yourself.

Your analogy falls down because that is not what happened. At all.

What would you say if your boss said: "We need some extra capabilities to stay competitive. It is going to mean some new skills and some extra work. So, Pedro here is going to help you. He is going to do this part and you are going to do that part. There may be some small changes to the way you do things in the future but, good news, it will not be any extra work for you because of Pedro here."

Can you honestly say you'd be like "uh, forget it boss. I do not share your opinions. We do not need to do that work. We do not need those outcomes. I won't do it. Not happening. Get over it."

Because, if you did, the proper outcome in that case is probably that your boss would fire you and that Pedro would take over. He would probably need to hire somebody to help.

See the difference?

The objection here was not to "the extra work". It was to the intended result. He flat out rejects that a mixed language code-base is better. He does not agree that adding Rust to Linux will make it a better kernel. So, he is blocking it. Sure, the "boss" (Linus) already decided that it was a good idea and that it should happen. He disagrees. So he does not care what the boss said. He is not playing ball.

Re-read your analogy and mine. See the difference?

Rambling

Posted Feb 12, 2025 23:53 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Because, if you did, the proper outcome in that case is probably that your boss would fire you and that Pedro would take over. He would probably need to hire somebody to help.

This capitalistic view that any worker is replaceable at any time with any other worker clashes very hard with the reality where this doesn't work at all :D

Sure you can try. But the chances of you succeeding to do that are really slim.

Rambling

Posted Feb 13, 2025 10:16 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> Sure you can try. But the chances of you succeeding to do that are really slim.

Is the guy a genius? Or is he a liability? Or is he both and which one outweighs the other? Managers are paid megabucks to make that decision (and if they take the money and don't do it, THEY are the liability ...).

But you pays your money and you makes your choice. I've actively declined (or pushed the manager for that decision) to hire somebody who was extremely capable. Because I (and everybody else) thought he would be a personal liability despite being clearly a technical genius.

Cheers,
Wol

Rambling

Posted Feb 13, 2025 16:04 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

Don't take this the wrong way but given the amount and content of comments you post here, I think in your team you're most likely to be the most hard to deal with.

Rambling

Posted Jan 30, 2025 21:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (33 responses)

> One guy (who already is overloaded) is not enthusiastic about adding yet another constraint to his work.

Then it's time to step aside. I'm serious. If you're overloaded and start to delay others because of your overload, then you should not try to fix the world and step aside. If some work is not done as a result of this, then it will force the stakeholders to allocate proper resources.

Rambling

Posted Jan 31, 2025 7:53 UTC (Fri) by siim@p6drad-teel.net (subscriber, #72030) [Link] (2 responses)

If they step aside, then the are zero guys to even get a terse rejection message from. I'm not sure what that would fix?

Rambling

Posted Jan 31, 2025 10:54 UTC (Fri) by khim (subscriber, #9252) [Link]

This will push the problem on other people and they will do something about it.

Someone would volunteer, or would be assigned, or some other resolution would happen.

Earth wouldn't stop spinning if one place in the kernel would be without a dedicated maintainer for the short time, believe me!

But as long as he continue to shoulder the burden others can pretend that everything is still peachy and there are no problem.

Rambling

Posted Jan 31, 2025 13:44 UTC (Fri) by dberlin (subscriber, #24694) [Link]

It is better for things to fail obviously, then to think they are not in a failing state.

When they fail obviously, it is hard to ignore, and often gets fixed.

When they are really being kept going by impossibly heroic efforts that are unsustainable, and so *appear* to not be in a failing state as a result, they rarely get fixed.

Rambling

Posted Jan 31, 2025 8:31 UTC (Fri) by tesarik (subscriber, #52705) [Link] (12 responses)

> If some work is not done as a result of this, then it will force the stakeholders to allocate proper resources.

I have the feeling it's no coincidence that you had to stay a bit vague in your statement. Can you elaborate on it, please? Be specific:

Who should do the work? Do they know? Are they committed to doing it, long-term?
Who is the stakeholder? Do they have the means to allocate proper resources?

I hope it's just me not being up to date, and everybody else knows there are good answers. Please, tell me.

Rambling

Posted Jan 31, 2025 11:18 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

> I hope it's just me not being up to date, and everybody else knows there are good answers.

You hope just shows that you don't understand what Cyberax proposed and why.

We don't know answer to these question – and the simplest, least stressful and contentious way to find out these answers… is for Christoph Hellwig to “step aside”.

Now, you say that answers to your questions are like this:

No one would ever be do the work that Christoph Hellwig did. No one would ever be able to learn to do it. No one would commit to it, long-term.
There would be no one who may decide who should “close the hole” left behind by Christoph Hellwig. Not Linus, not Greg and not all the hudreds of thousands engineers in Amazon, Google, Meta, Microsoft and other companies that use Linux. And no one else would be able to allocate resources, too.
This would, of course, have severe consequences:
Azure would have to move all customers to Windows
Android would have to replace Linux kernel with Zircon
Routers would have to switch to QNX or maybe they would have to adopt FreeBSD (like SONY does on most consoles)
This would be huge disruption to the global economy

Now, how likely is such an outcome. Do you really believe that's what would happen?

If yes, and if without Christoph Hellwig Linux kernel is doomed and would die… I think it's still the best he could do is to abandon it ASAP. Sure, if it'll turn out that billions of people rely on something that only a single person in the whole world can ever do and if it's true that no one may ever replace him… then it's better to start replacing it with some other alternatives for what other choice is there?

It's not as if we may count of Christoph Hellwig to still support Linux in year 2525, 500 years from now, do we? He's not immortal, for one thing.

Rambling

Posted Jan 31, 2025 17:35 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

He's not immortal, for one thing.

How would you know? If maintaining the DMA code really requires the god-like powers people seem to ascribe to Christoph Hellwig, then mere immortality sounds like a straightforward side hustle.

Rambling

Posted Jan 31, 2025 19:55 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> How would you know?

Good point…

> If maintaining the DMA code really requires the god-like powers people seem to ascribe to Christoph Hellwig

That's not me, that's @tesarik's idea that he couldn't be replaced.

> then mere immortality sounds like a straightforward side hustle

So have we accidentally discovered the identity of Emperor of the Mankind… prematurely?

And after some thinking… I think that even in that case it's better to assume that he can die.

I mean… even if he is, technically, immortal… is it actually wise to build the whole civilization around the abilities of one man? Would he still be able to support DMA code while entombed in the… we know where?

That future… is not very pretty. Or stable.

Rambling

Posted Jan 31, 2025 20:05 UTC (Fri) by tesarik (subscriber, #52705) [Link]

> That's not me, that's @tesarik's idea that he couldn't be replaced.

I didn't want to reply to your blatant straw man fallacy, but now I realize there was another commenter with that kind of thinking:

https://lwn.net/Articles/1007136/

So for the record, that's not me.

Rambling

Posted Feb 1, 2025 0:33 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

The Emperor is listed as only one of several Perpetuals, they're all immortal. For whatever that's worth in 40K which is very little since what actually matters is a form of "plot armour". If it's better to keep you around the story will change so that you don't die.

In most cases 40K's silliness just annoys me, but I found that it does fix one game, Talisman. Relic is basically Talisman but with the 40K background as rationale. Talisman is a very silly game, but in the 40K setting of Relic that feels appropriate.

Rambling

Posted Jan 31, 2025 17:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Linux is not a hobby Github project with 3 contributors. Somebody will step in. It also doesn't have to be a lifetime tenure, DMA is a complicated subsystem, but it's nothing that requires 10 years of study to work on.

And it's not even unprecedented in _Linux_. That's exactly what happened with the real-time Linux project several years ago. The sole developer heroically pushing it threatened to step aside, and somehow magically the funding appeared.

Rambling

Posted Feb 2, 2025 21:34 UTC (Sun) by andy_shev (subscriber, #75870) [Link] (5 responses)

What I was trying to tell in the previous reply that you can switch maintainer or developer, but how efficient and qualified the switch would be? If they match, okay, that person may even become a co-maintainer to begin with, no? Have we seen anybody from Rust to help with C code? Their proposal AFAIU it is to maintainer the Rust code only. Not every maintainer would be happy about this.

Rambling

Posted Feb 2, 2025 21:38 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> What I was trying to tell in the previous reply that you can switch maintainer or developer, but how efficient and qualified the switch would be?

My point is that it doesn't matter. At all. If you don't have processes that result in a reasonable handover, then you've already failed. You just don't know it yet.

> Have we seen anybody from Rust to help with C code?

Yes, and usually C guys don't want it (see: the DRM fiasco).

Rambling

Posted Feb 3, 2025 13:02 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> > What I was trying to tell in the previous reply that you can switch maintainer or developer, but how efficient and qualified the switch would be?

> My point is that it doesn't matter. At all. If you don't have processes that result in a reasonable handover, then you've already failed. You just don't know it yet.

Any human endeavour that wants to survive - any endeavour that a human wants to survive - NEEDS succession planning.

The current situation seems to be that the incumbent(s) are actively *sabotaging* any attempt at succession. Which means that if the bus (factor) hits, the Linux kernel will be in serious trouble.

Give him his due, Linus has always been pretty good at succession planning - Alan Cox, Greg KH, I can think of a couple more whose names I can't remember. Maintainers who sabotage succession planning need to be sidelined. We don't want a bus anywhere near them ...

Cheers,
Wol

Rambling

Posted Feb 4, 2025 6:32 UTC (Tue) by nksingh (subscriber, #94354) [Link]

Not to say anything about this specific case, but:
Science progresses one funeral at a time.
https://en.m.wikipedia.org/wiki/Planck%27s_principle

I work at msft, but I'm sure it's the same at all the bigcorps. A new generation of engineers on an old system make the same old mistakes again, but eventually they learn and build something newer and better.

Rambling

Posted Feb 3, 2025 18:51 UTC (Mon) by asahilina (subscriber, #166071) [Link] (1 responses)

> the DRM fiasco

Just to clarify, the DRM issue was with one DRM subcomponent specifically, `drm_sched`, and one maintainer. The top-level DRM maintainers are lovely folks and so is most of the rest of the team, and I haven't had issues getting changes upstreamed to all the other pieces of DRM.

Rambling

Posted Feb 18, 2025 9:18 UTC (Tue) by daenzer (subscriber, #7050) [Link]

Not really seeing much similarity between these two situations (admittedly having witnessed only "the DRM fiasco" first-hand). The latter was about technical issues in the proposed patches, no DRM maintainer said anything like "I don't want Rust in the kernel" or "Rust is cancer". Raising issues in proposed patches is the job of a maintainer.

Rambling

Posted Feb 2, 2025 21:24 UTC (Sun) by andy_shev (subscriber, #75870) [Link] (16 responses)

You probably missed the situation. If a maintainer, like Christoph Hellwig, steps down, the whole kernel becomes a pile of ruins very quickly. Probably he implied that what Rust people should do, is to start helping with C code in the critical areas and get used to it to understand how all this works. OTOH, I dunno how on earth the VFS layer got so easy to walk with Rust.

Personally I was trying to understand the (real) benefit of this experiment to Linux kernel and failed. The option which is not mentioned, though, is to create a full OS kernel in Rust from scratch, but hold on... it seems already at least two such projects exists, and what I have been told, they are not the same people (at all) as those who are keeping their hope on Linux kernel.

Rambling

Posted Feb 2, 2025 21:29 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> You probably missed the situation. If a maintainer, like Christoph Hellwig, steps down, the whole kernel becomes a pile of ruins very quickly.

No. I'm not missing it. I'm saying that the situation that you're describing is NOT acceptable. A project the size of the Linux kernel can't depend on individual, overworked people.

> Probably he implied that what Rust people should do, is to start helping with C code in the critical areas and get used to it to understand how all this works.

Let's reverse it? Should Rust people ask him to help with Rust maintenance to speed up the kernel transition to a more productive language?

Rambling

Posted Feb 2, 2025 21:38 UTC (Sun) by andy_shev (subscriber, #75870) [Link] (5 responses)

And it depends on them... Haven't you followed the LWN article where burnout was mentioned as a main problem for Linux kernel maintainers? On top of that look at the statistics: each release we have a dozen of hundreds usual contributors to it, the community is not simply growning fast enough. Of course, one can tell that there are potential candidates for this or that, but in practice it will mean the fading phase of the project as a whole.

Rambling

Posted Feb 2, 2025 21:43 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> And it depends on them... Haven't you followed the LWN article where burnout was mentioned as a main problem for Linux kernel maintainers?

Yes. And that's why a good remedy is to step aside.

Rambling

Posted Feb 3, 2025 9:13 UTC (Mon) by andy_shev (subscriber, #75870) [Link] (3 responses)

Are you nominating somebody to do the job? Or you are proposing something you are not responsible for? This is nice play, if so!

Rambling

Posted Feb 3, 2025 18:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Should I remind you what happened when the RT Linux maintainers stepped aside?

Rambling

Posted Feb 11, 2025 15:25 UTC (Tue) by andy_shev (subscriber, #75870) [Link] (1 responses)

Irrelevant. For RT Linux were real customers behind with $$$, behing Rust no-one with $$$. Or if you are talking about DMA mapping in C, that's another story.

Rambling

Posted Feb 11, 2025 17:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Large companies are backing Rust, including Google for Android. Binder was one of the first real Rust drivers.

Rambling

Posted Feb 2, 2025 21:40 UTC (Sun) by andy_shev (subscriber, #75870) [Link] (6 responses)

Ah, and for your second question: It doesn't work like this. It's they who came to the project and not him who went to Rust and telling them about their project. See the difference?

Rambling

Posted Feb 2, 2025 21:44 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Why doesn't it work? C developers who disagree are free to fork the kernel and make a "Veteran C Developer" project.

Rambling

Posted Feb 3, 2025 9:12 UTC (Mon) by andy_shev (subscriber, #75870) [Link] (2 responses)

Because it's a newcomer's responsibility to follow the (established) rules of the project, and not otherwise.

Rambling

Posted Feb 3, 2025 9:14 UTC (Mon) by intelfx (subscriber, #130118) [Link] (1 responses)

So far, “rules of the project” are that Rust is greenlit as an experiment.

Rambling

Posted Feb 3, 2025 12:29 UTC (Mon) by andy_shev (subscriber, #75870) [Link]

Yes, and not only technical experiment. Seems social part of it is not less interesting.

Rambling

Posted Feb 5, 2025 5:44 UTC (Wed) by ssmith32 (subscriber, #72404) [Link] (1 responses)

The kernel is as much "their" project as it is his.

He maintains a key part of the project, but relative to the kernel as a whole, it's a small part.

He's not Linus, and he's certainly not Greg. It's not his project.

Rambling

Posted Mar 2, 2025 20:28 UTC (Sun) by andy_shev (subscriber, #75870) [Link]

The first statement is an obvious mistake. The Rust thingy is way too young in comarison to the Linux kernel project (and even younger if you look at the first considerations to use Rust inside Linux kernel).
The last statement is also false. LK is the project of the community, and it is his project as well as Linus' or Greg's.

Rambling

Posted Feb 3, 2025 1:55 UTC (Mon) by dralley (subscriber, #143766) [Link]

>> Probably he implied that what Rust people should do, is to start helping with C code in the critical areas and get used to it to understand how all this works.

One of the previous dustups between the Rust and C developers was triggered by C developers basically refusing to document or explain (or even come to an agreement on) the precise semantics of some of the existing C APIs.

Obviously it's not sustainable to have a kernel development process that can't find time for that. Even for up-and-coming C developers, the only way that knowledge gets efficiently shared is by _sharing_ it.

Rambling

Posted Feb 3, 2025 10:25 UTC (Mon) by farnz (subscriber, #17727) [Link]

If a maintainer, like Christoph Hellwig, steps down, the whole kernel becomes a pile of ruins very quickly

This is then an existential problem for the kernel, regardless of whether he steps down because he doesn't like Linus's decisions on technical direction or not.

There is nothing we can do to guarantee that Hellwig (or you, or me, or any other human being) will survive the next 30 minutes, for any value of "the next 30 minutes"; even if he takes all possible precautions, there's still the risk of a meteorite strike or a sudden death from a previously undiagnosed health condition in a physically active and otherwise healthy adult. This is just the nature of being humans - you cannot guarantee that we'll hang around, no matter what you do.

And in many respects, it's better for the project if we can fix this while Mr Hellwig is still in good health. If he's still around to help out as and when he feels like it, it becomes possible to get his input on things where his unique knowledge and experience is needed. We might need someone to pay him a considerable consulting fee, but that's still hugely ahead of the situation where we can't get him to explain something at all and have to deduce it from the code.

Rambling

Posted Jan 31, 2025 1:28 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (13 responses)

Rust is not a trend. It is not a fashion statement. It is not an arbitrary aesthetic choice. It is a step-function improvement in the safety, security, and robustness of an information ecosystem on which billions of people depend. It is here to stay. To slow its adoption is reckless. To insist we use C and only C is to insist that we build houses with asbestos insulation and drive cars powered by leaded gasoline while we smoke the cigarettes of the brand that nine out of ten doctors recommend.

Linux is too big, too important, and too exposed to attack to remain stuck in the 1970s memory-unsafe paradigm. If a critical mass of developers insists on blocking progress, these developers will have to be bypassed using the affordances the GPLv2 makes for independent development.

Rambling

Posted Jan 31, 2025 2:22 UTC (Fri) by dralley (subscriber, #143766) [Link] (11 responses)

That's perhaps a touch hyperbolic, but the point remains that this is a project deliberately invited and cultivated by Linus and Greg KH, and a single maintainer shouldn't get to arbitrarily "veto" 3+ years down the line just because they feel like it, without providing an even slightly reasonable justification, and doing so in an incredibly flippant and disrespectful way.

The rules of engagement are already so heavily tilted in favor of the existing maintainers. At some point this just looks like guarding a fiefdom from "newcomers". Not a great attitude for the long-term health of the kernel.

Rambling

Posted Jan 31, 2025 4:52 UTC (Fri) by jbowen (subscriber, #113501) [Link]

And doing so on v8 of the patchset

Rambling

Posted Jan 31, 2025 8:43 UTC (Fri) by intelfx (subscriber, #130118) [Link] (7 responses)

> a single maintainer shouldn't get to arbitrarily "veto" 3+ years down the line just because they feel like it, without providing an even slightly reasonable justification, and doing so in an incredibly flippant and disrespectful way.

I think we have our justification:

https://lwn.net/ml/all/20250131075751.GA16720@lst.de/

As I read it, this is indeed an explicit attempt to veto the entire project.

Rambling

Posted Jan 31, 2025 9:09 UTC (Fri) by MKesper (subscriber, #38539) [Link] (6 responses)

"The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this. ... I do not want it anywhere near a huge C code base that I need to
maintain."

No comment needed, I guess.

Rambling

Posted Jan 31, 2025 9:28 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (5 responses)

Oh well, let's thank Mr Hellwig for his huge contribution to Linux until now, and wish him success in his new endeavours beyond the kernel project.

Rambling

Posted Jan 31, 2025 10:10 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (4 responses)

I think you overestimate the amount of capable kernel maintainers who can replace him.

Rambling

Posted Jan 31, 2025 12:38 UTC (Fri) by pizza (subscriber, #46) [Link]

> I think you overestimate the amount of capable kernel maintainers who can replace him.

Not to mention overestimating the nature of what can be done when you're not actually _employed_ by the ones wanting the changes.

Rambling

Posted Feb 2, 2025 3:02 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (2 responses)

Frankly, I am starting to believe that this whole thing is a tempest in a teapot. The patch is now on version 11[1]. As far as I can tell, none of the responses to versions 9 through 11 contain any acknowledgement whatsoever that Christoph nacked version 8. Version 9 did introduce a MAINTAINERS entry for the new Rust stuff, despite Christoph specifically saying he didn't want another maintainer.

In other words, it would seem that everyone has tacitly agreed to totally ignore Christoph's objections, add maintainers for the Rust code, and move on as if nothing happened. Perhaps this comment section should do the same.

[1]: https://lore.kernel.org/rust-for-linux/20250123104333.134...

Rambling

Posted Feb 2, 2025 7:48 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

> Frankly, I am starting to believe that this whole thing is a tempest in a teapot. The patch is now on version 11[1]. As far as I can tell, none of the responses to versions 9 through 11 contain any acknowledgement whatsoever that Christoph nacked version 8. Version 9 did introduce a MAINTAINERS entry for the new Rust stuff, despite Christoph specifically saying he didn't want another maintainer.

As I understand, all three subsequent submissions (on January 21st and 23rd) happened well before the NAK (January 28th), so it doesn't seem like there is any final resolution to this story yet.

You're right, however, that it likely won't be helped by flaming in the LWN comment section.

Rambling

Posted Feb 2, 2025 18:22 UTC (Sun) by SLi (subscriber, #53131) [Link]

To me this sounds more like sides digging in before the real fight begins. Having said that, I do think—as someone with not very deep insight into kernel development dynamics—this is likely to be merged in one form or another, which is what the patch submitters are also counting on by continuing to develop it. And the "fight" may turn out to be over before it begins if Linus pulls the series, but... I actually suspect someone intervening to force a short discussion instead of just a fiat could be a better outcome for the community. Even if someone is behaving unreasonably, it might be better to take it as a scream for help.

Rambling

Posted Jan 31, 2025 10:13 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

You can invite and cultivate whatever you want, but you can't give extra work to people who don't want extra work.

Rambling

Posted Jan 31, 2025 15:48 UTC (Fri) by jengelh (guest, #33263) [Link]

>At some point this just looks like guarding a fiefdom from "newcomers".

The pre-git and LWN history is not as detailed as the coverage in this decade, so judging who was a "newcomer" back then is difficult. But looking at code/topics, there have been at least two where entire subsystems were reverted/removed, something that I suspect would not happen with active-and-experienced participants.

devfs - https://lwn.net/Articles/139595/
IDE rewrites - https://lwn.net/Articles/8123/

Rambling

Posted Feb 4, 2025 17:06 UTC (Tue) by sionescu (subscriber, #59410) [Link]

> Rust is not a trend. It is not a fashion statement. It is not an arbitrary aesthetic choice.

It is, to a great extent, all three.