Resistance to Rust abstractions for DMA mapping
DMA transfers move data directly between RAM and the device of interest, without involving the CPU. It is difficult to get any sort of reasonable I/O performance without DMA, so almost all devices support it. Making DMA work, though, is not just a matter of handing a memory address to a peripheral device; there are many concerns that must be dealt with. These include maintaining cache coherency, ensuring that pages are resident in RAM, handling device-specific addressing limitations, programming I/O memory-management units, and more. Plus, of course, every architecture does things differently. The DMA-mapping layer exists to hide most of these problems from device drivers behind an architecture-independent interface.
Drivers written in Rust will need to do DMA, so they will need access to the mapping layer. There have been patches to provide some of that access in circulation for some time; Abdiel Janulgue posted a version of this work in early January. This series adds a small Rust module with sufficient support to set up coherent mappings (long-term mappings in cache-coherent memory) for drivers. This work only covers part of the DMA API, but it is sufficient for simpler devices. Upcoming drivers will require that these abstractions are in place.
But Christoph Hellwig, who does a lot of work with the DMA-mapping layer,
turned this submission
away with a message reading, in its entirety: "No rust code in
kernel/dma, please
" (despite the fact that the patch did not put any
code in that directory). When pressed, he added that developers
should keep these abstractions in their own code and said that he had no
interest in maintaining multi-language code. Rust developers should keep
their wrapping code to themselves, he concluded.
Danilo Krummrich pointed out
that the proposed abstractions were doing exactly that — keeping the Rust
code separate from the rest: "We wrote a single piece of Rust code that
abstracts the C API for all Rust drivers, which we offer to maintain
ourselves
". The conversation then went quiet for several days, after
which Krummrich said:
"Since there hasn't been a reply so far, I assume that we're good with
maintaining the DMA Rust abstractions separately
".
Hellwig, though, made it
clear that he is not on board with that plan. He does not want the
Rust code anywhere near the DMA layer, and that fact that somebody else
would be maintaining it does not change his view. Adding another language
(he was clear that he was talking about any language, not Rust in
particular) would, he said, make Linux as a whole "impossible to
maintain
". That has, for now, brought the conversation to a halt.
Without DMA support, there can be no interesting drivers written in Rust. So one option that the Rust-for-Linux developers have at this point is to give up on the whole thing and find a less frustrating project to work on. As appealing as this option might be, it still is probably not their first choice, though.
An alternative would be to do what Hellwig is suggesting and put the abstractions into each driver that needs them. That, however, is not a path toward a more maintainable kernel. When the DMA API changes, as it inevitably will, numerous drivers will have to be fixed, one by one, rather than fixing a single set of abstractions that are used by all. So this, too, might not appear at the top of the list of options as seen by the developers involved.
Yet another approach might be to stash the DMA abstractions somewhere out of Hellwig's immediate sight — not in the kernel/dma directory, in other words. At that point it becomes just another user of the DMA API that, in theory, is not subject to more scrutiny than any other driver. The only problem with this idea is that Janulgue's patch already does that, and it was not sufficient.
Someday, there will need to be a more decisive answer to this
question. Krummrich has tried to bring this about with a note asking for Linus Torvalds
or Greg Kroah-Hartman to make a decision regarding these abstractions.
Other Rust developers have reiterated
that they would take responsibility for the maintenance of this code, and
that it would not affect the DMA subsystem. Jason Gunthorpe questioned that last
claim, noting that a 6.14 pull request was delayed due to a Rust build
problem, but Kroah-Hartman answered that it was
"a tooling issue that people missed due to the holidays
" rather than
an example of Rust code holding up development. Neither he nor Torvalds
has made any decrees on whether the code in question will be merged, though.
By allowing the entry of Rust, the kernel community has decided — on a provisional basis, at least — that it is indeed willing to maintain a multi-language code base. Perhaps, for now, the desire to banish Rust code to the periphery of the kernel makes some sense, while Rust is still seen as an ongoing experiment. If it is eventually decided that the Rust experiment has failed, backing the existing Rust code out will be easier if it's confined to the edges.
But it seems increasingly unlikely that the Rust experiment will be judged that way. Rust clearly can be used to write kernel code, and there would appear to be some significant advantages to doing that. If the experiment has indeed succeeded then, at some point, the language will need to be treated as a first-class citizen within the kernel. Over time, "I don't want to deal with more than one language" will be an increasingly weak argument against a contribution written in Rust.
That day may be a while in coming yet. Already overworked kernel
maintainers will have to find time to learn Rust well enough to manage it
within their subsystems. Incoming Rust developers can shoulder some of
that burden, but they too will need time to acquire anywhere near the level of
experience that the current maintainers have — experience that the kernel
community depends on heavily. A change of this magnitude to a body of code
as large as the kernel was never going to be a quick or easy affair; it has
gone as well as could have been expected so far, but there will be more,
perhaps harder, obstacles to overcome in the future.
| Index entries for this article | |
|---|---|
| Kernel | Development tools/Rust |
| Kernel | Direct memory access |
Posted Jan 30, 2025 20:00 UTC (Thu)
by Poliorcetics (subscriber, #165001)
[Link] (82 responses)
One guy is:
- Blocking abstractions in his domain because he only wants C, which I don’t agree with but ok
That entire thread is a sad example of open source because one person feels like ruining it for everyone else.
Posted Jan 30, 2025 20:49 UTC (Thu)
by tesarik (subscriber, #52705)
[Link] (67 responses)
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…
Posted Jan 30, 2025 20:58 UTC (Thu)
by mb (subscriber, #50428)
[Link] (3 responses)
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.
Posted Jan 31, 2025 10:07 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Jan 31, 2025 13:12 UTC (Fri)
by dralley (subscriber, #143766)
[Link]
Posted Jan 31, 2025 13:41 UTC (Fri)
by dberlin (subscriber, #24694)
[Link]
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.
Posted Jan 30, 2025 21:03 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (28 responses)
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 …
Posted Jan 31, 2025 0:45 UTC (Fri)
by cloehle (subscriber, #128160)
[Link] (27 responses)
Unless I've missed something that isn't upstream though?
Posted Jan 31, 2025 0:51 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (26 responses)
Posted Jan 31, 2025 10:12 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (25 responses)
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"?
Posted Jan 31, 2025 10:58 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Jan 31, 2025 15:45 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted Feb 12, 2025 20:50 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link]
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.
Posted Jan 31, 2025 10:59 UTC (Fri)
by gioele (subscriber, #61675)
[Link] (3 responses)
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.)
Posted Jan 31, 2025 15:47 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
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.
Posted Jan 31, 2025 18:09 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Posted Feb 5, 2025 5:23 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Code, not maintained by him, breaks, and holds up a release.
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.
Posted Jan 31, 2025 13:16 UTC (Fri)
by ms-tg (subscriber, #89231)
[Link] (2 responses)
Can you dive a click deeper on the extra work that you are seeing being asked or the DMA maintainer?
Posted Jan 31, 2025 15:57 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
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.
Posted Jan 31, 2025 16:28 UTC (Fri)
by dralley (subscriber, #143766)
[Link]
Posted Jan 31, 2025 13:42 UTC (Fri)
by dberlin (subscriber, #24694)
[Link] (6 responses)
Actually, no, they offered to maintain it separately as well, and he nacked that too!
Posted Jan 31, 2025 16:22 UTC (Fri)
by tesarik (subscriber, #52705)
[Link] (5 responses)
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?
Posted Feb 4, 2025 8:42 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (4 responses)
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.
Posted Feb 4, 2025 20:20 UTC (Tue)
by tesarik (subscriber, #52705)
[Link] (3 responses)
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.
Posted Feb 5, 2025 1:31 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (2 responses)
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:
"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.
Posted Feb 5, 2025 1:38 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
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.
Posted Feb 5, 2025 17:33 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 1, 2025 10:43 UTC (Sat)
by intelfx (subscriber, #130118)
[Link] (3 responses)
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.
Posted Feb 1, 2025 10:59 UTC (Sat)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Feb 1, 2025 11:07 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
Posted Feb 1, 2025 15:21 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 12, 2025 20:36 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link] (3 responses)
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?
Posted Feb 12, 2025 23:53 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
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.
Posted Feb 13, 2025 10:16 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Feb 13, 2025 16:04 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
Posted Jan 30, 2025 21:04 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (33 responses)
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.
Posted Jan 31, 2025 7:53 UTC (Fri)
by siim@p6drad-teel.net (subscriber, #72030)
[Link] (2 responses)
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.
Posted Jan 31, 2025 13:44 UTC (Fri)
by dberlin (subscriber, #24694)
[Link]
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.
Posted Jan 31, 2025 8:31 UTC (Fri)
by tesarik (subscriber, #52705)
[Link] (12 responses)
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:
I hope it's just me not being up to date, and everybody else knows there are good answers. Please, tell me.
Posted Jan 31, 2025 11:18 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
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: 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.
Posted Jan 31, 2025 17:35 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (3 responses)
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.
Posted Jan 31, 2025 19:55 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Good point… That's not me, that's @tesarik's idea that he couldn't be replaced. 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.
Posted Jan 31, 2025 20:05 UTC (Fri)
by tesarik (subscriber, #52705)
[Link]
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.
Posted Feb 1, 2025 0:33 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Jan 31, 2025 17:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
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.
Posted Feb 2, 2025 21:34 UTC (Sun)
by andy_shev (subscriber, #75870)
[Link] (5 responses)
Posted Feb 2, 2025 21:38 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
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).
Posted Feb 3, 2025 13:02 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
> 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,
Posted Feb 4, 2025 6:32 UTC (Tue)
by nksingh (subscriber, #94354)
[Link]
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.
Posted Feb 3, 2025 18:51 UTC (Mon)
by asahilina (subscriber, #166071)
[Link] (1 responses)
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.
Posted Feb 18, 2025 9:18 UTC (Tue)
by daenzer (subscriber, #7050)
[Link]
Posted Feb 2, 2025 21:24 UTC (Sun)
by andy_shev (subscriber, #75870)
[Link] (16 responses)
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.
Posted Feb 2, 2025 21:29 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
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?
Posted Feb 2, 2025 21:38 UTC (Sun)
by andy_shev (subscriber, #75870)
[Link] (5 responses)
Posted Feb 2, 2025 21:43 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Yes. And that's why a good remedy is to step aside.
Posted Feb 3, 2025 9:13 UTC (Mon)
by andy_shev (subscriber, #75870)
[Link] (3 responses)
Posted Feb 3, 2025 18:30 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Feb 11, 2025 15:25 UTC (Tue)
by andy_shev (subscriber, #75870)
[Link] (1 responses)
Posted Feb 11, 2025 17:17 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 2, 2025 21:40 UTC (Sun)
by andy_shev (subscriber, #75870)
[Link] (6 responses)
Posted Feb 2, 2025 21:44 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Feb 3, 2025 9:12 UTC (Mon)
by andy_shev (subscriber, #75870)
[Link] (2 responses)
Posted Feb 3, 2025 9:14 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Posted Feb 3, 2025 12:29 UTC (Mon)
by andy_shev (subscriber, #75870)
[Link]
Posted Feb 5, 2025 5:44 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link] (1 responses)
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.
Posted Mar 2, 2025 20:28 UTC (Sun)
by andy_shev (subscriber, #75870)
[Link]
Posted Feb 3, 2025 1:55 UTC (Mon)
by dralley (subscriber, #143766)
[Link]
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.
Posted Feb 3, 2025 10:25 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
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.
Posted Jan 31, 2025 1:28 UTC (Fri)
by quotemstr (subscriber, #45331)
[Link] (13 responses)
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.
Posted Jan 31, 2025 2:22 UTC (Fri)
by dralley (subscriber, #143766)
[Link] (11 responses)
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.
Posted Jan 31, 2025 4:52 UTC (Fri)
by jbowen (subscriber, #113501)
[Link]
Posted Jan 31, 2025 8:43 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (7 responses)
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.
Posted Jan 31, 2025 9:09 UTC (Fri)
by MKesper (subscriber, #38539)
[Link] (6 responses)
No comment needed, I guess.
Posted Jan 31, 2025 9:28 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link] (5 responses)
Posted Jan 31, 2025 10:10 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (4 responses)
Posted Jan 31, 2025 12:38 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Not to mention overestimating the nature of what can be done when you're not actually _employed_ by the ones wanting the changes.
Posted Feb 2, 2025 3:02 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
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...
Posted Feb 2, 2025 7:48 UTC (Sun)
by intelfx (subscriber, #130118)
[Link] (1 responses)
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.
Posted Feb 2, 2025 18:22 UTC (Sun)
by SLi (subscriber, #53131)
[Link]
Posted Jan 31, 2025 10:13 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link]
Posted Jan 31, 2025 15:48 UTC (Fri)
by jengelh (guest, #33263)
[Link]
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/
Posted Feb 4, 2025 17:06 UTC (Tue)
by sionescu (subscriber, #59410)
[Link]
It is, to a great extent, all three.
Posted Jan 30, 2025 20:26 UTC (Thu)
by mb (subscriber, #50428)
[Link] (97 responses)
The real cancer of the kernel is hostile maintainers who don't think they need actual arguments in discussions.
This is not even special to interacting with the R4L project.
There are so many nice people (and maintainers) in kernel development, but a couple of persons make this whole environment extremely unpleasant.
This hurts Linux as a whole.
Posted Jan 30, 2025 21:54 UTC (Thu)
by npws (subscriber, #168248)
[Link]
It seems to me its the same handful every time. The vast majority have proper manners and are reasonably easy to work with.
Posted Jan 31, 2025 5:31 UTC (Fri)
by atai (subscriber, #10977)
[Link] (95 responses)
sorry. The maintainers are Linux, as people who maintain Linux and keep it alive. Then, it follows, whoever tries to spread foreign things the maintainers are hostile, to Linux, the foreign things are the cancer.
Posted Jan 31, 2025 6:49 UTC (Fri)
by mb (subscriber, #50428)
[Link] (94 responses)
I find the wording of calling something "cancer" outright disgusting. So I flipped it and applied it to the people using such wording. (This is not the first time something like this happens and he's not the only person doing this)
Please use actual arguments and name problems when rejecting something, because problems can be solved.
>The maintainers are Linux, as people who maintain Linux and keep it alive.
So they can't be wrong?
Posted Jan 31, 2025 10:06 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (90 responses)
The problem is that they will be forced to take on extra work in a language they don't know. And that means several months of extra work just to learn it at that level.
I think it is completely justified for people to say "no, I don't want to do this" and it seems very ill advised to try and force them, because they might decide to quit completely.
I know something about it because after Torvalds decided to talk shit about me (without naming me) at a conference, while of course doing some major edits to the real story to look like he was right, I quit working on subsurface and removed it from debian. Now as a result that software is not easy to run on debian, but Torvalds has had his fun trolling. Was it worth it? Probably to him it was.
Anyway making me quit from a fringe project and make several core maintainers quit from the linux kernel would have very very different impact.
Posted Jan 31, 2025 10:37 UTC (Fri)
by npws (subscriber, #168248)
[Link] (21 responses)
But I don't think it will come to that. Torvalds has made the decision three years ago, and given that Helwig is not complaining about any specific "extra work" he should do, but voicing very generic opposition, it is to be expected that he will be overruled and most likely will simply deal with it.
Posted Jan 31, 2025 15:38 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (20 responses)
So while the world will keep on going just fine, the kernel project (or any other project) might not, if it loses a few important contributors.
Posted Jan 31, 2025 15:58 UTC (Fri)
by corbet (editor, #1)
[Link] (13 responses)
Posted Jan 31, 2025 17:41 UTC (Fri)
by dralley (subscriber, #143766)
[Link] (5 responses)
Linus himself has talked about how many patches come in as one-offs, and how it's a challenge to find the kind of people who will spend years learning, building trust and contributing to a degree that they could potentially become a maintainer or authority of some kind.
Posted Feb 7, 2025 10:39 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (4 responses)
Posted Feb 7, 2025 13:15 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
Posted Feb 7, 2025 14:54 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
But companies have motivation (or rather the people within them do). If the kernel community actively demotivate outsiders - paid or not - that's a bad thing.
What's the difference between the kernel community de-motivating contributors, and a company de-motivating customers? NOTHING. Both are actively shrinking the pool of people willing to do business with them, and both are actively hastening their own demise.
Whether I'm paid or not has nothing to with whether I have a bad experience or not. And if I have that bad experience, next time I'm asked to go back there I will actively resist. If I'm paid and my boss has to pull rank, that puts him off and makes him less likely to want to deal with them too.
Even - or especially! - if they're paid to do so, you do not want to give the people the motivation to NOT come back.
Cheers,
Posted Feb 7, 2025 15:24 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
I'm sorry, I didn't make my point clear.
Companies pay folks to contribute stuff, but once that "stuff" is contributed (eg add a new driver or a fix for an existing driver) from their employer's perspective, there is no longer any need for those folks to continue engaging with the kernel as a whole, so they are tasked with doing other things instead. Voila, drive-by contribution.
While those individuals _could_ continue to do other things with the Linux, but that would have to come from their off-the-clock time, and unlike $dayjob where you do what you're told, on one's own time there are innumerable other things you could do. Such as being with with their families or going outside, ie "anything other than spending even more hours staring at a computer screen performing unpaid, hard, thankless *work*)
In order to gain the level of expertise and experience necessary to rise up to the level of a subsystem maintainer, one has to spend literally *years* getting your hands dirty on Linux's internals on a more-than-full-time basis. Very few folks have the opportunity to do so.
Posted Feb 7, 2025 16:35 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
And you don't seem to have understood mine.
If my boss tells me to do something I find unpleasant, I will not want to repeat the experience! And in jurisdictions where "hire and fire" is not the norm, my boss will find it very hard to make me do it again. "Give it to someone else!". Payment has NOTHING to do with it.
And if the boss can't find people willing to interact with the kernel community, that could be another reason why so many companies ship outdated kernels with their gear - it's not that they don't want to ship updated stuff, it's that they can't find staff willing to go through the grief of upstreaming the stuff they need ...
(People of that calibre are likely people that could just walk if they so desired ...)
Cheers,
Posted Feb 1, 2025 18:24 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
That takes easily a decade of dedicated work to really do well, and we've been feeling the lack of it in filesystem and mm land - remember Linus saying "nobody understands mm" - mm has also fared poorly with retaining people with key knowledge...
And as Rust is rising fewer and fewer people are taking the time to get really good at C; understandably, since that also easily takes a decade...
It's easily to look at headline numbers and say "everything is great", but if you dig deeper I think we've got some real challenges ahead.
Posted Feb 1, 2025 22:37 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (3 responses)
Rust won't save you from learning much of that of course, but it puts nice shiny padlocks onto those trapdoors which you can't overlook – you get compiler errors when you do – and aren't supposed to open (i.e. you don't get to use "unsafe").
I do wonder how much of some people's reluctance to learn Rust can be attributed to the Sunk Cost fallacy …
Posted Feb 1, 2025 22:48 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
You are describing the *what*, but what matters even more (from a maintainer's perspective) is the *why*.
> Rust won't save you from learning much of that of course,
Rust helps express the *what* far more formally, but it won't tell you *why* this approach was taken. That level of understanding tends to come with the acquisition of scars.
Posted Feb 1, 2025 23:14 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link]
The problem of insufficient, inadequate and imprecise human communication will remain out of reach for a bit longer :)
But anything that helps with the tedium does free up cycles for those "higher minded" issues, and besides I expect that better and more expressive type systems will help somewhat with the "why" issue as well, just because we'll have names for things that are more typically open coded today. C is not ideal for generic programming.
Posted Feb 3, 2025 8:47 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
That's right at first glance, *but* when I can address the "what" in code, adding a comment that describes the "why" along with it is at least conceivable.
In C however you can't even express the "what" parts of your restrictions, so *that* ends up in documentation (we hope) and the "why" tends to fall by the wayside.
Posted Feb 5, 2025 18:35 UTC (Wed)
by ljsloz (subscriber, #158382)
[Link] (1 responses)
Who specifically are you thinking of? Because I'm an mm (co-maintainer) AND a relatively 'new' person (at least professionally) and I've not found this to be the case at all.
(For the sake of the topic - I have written a 1,300 page book on mm, documentation on esoteric mm locking, constantly refactor code to make it easier to understand/refactor/extend, added a whole userland vma testing framework to be able to very very quickly exercise/test behaviour there - so hey - I'm maybe one of the biggest proponents of providing mm knowledge out there who has walked-the-walk on that).
On the rust front, I'm also a huge proponent of it, as are many mm people, I for one have some real credibility here as I've reviewed the rust mm wrapper series at length and put a great deal of effort in explaining mm internals, discussing and promoting that series.
Supporting rust in mm isn't mutually exclusive with people in mm having deeper knowledge...!
Also that Linus quote seems to me to be quite obviously tongue-in-cheek right?
Posted Feb 6, 2025 2:44 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Thanks for the work!
For people, Ric van Riel left for awhile (though I see he's back!), Johannes Weiner seems to be moving into management, there's been cycling in slab/slub (Vlastimil has been great to work with recently, though).
I've worked in a lot of areas of the kernel - block and filesystems the most - and mm has consistently been a pain point. It's very central, and yet it's been hard to get a lot of things done in a lot of areas because there hasn't seemed to be clear responsibility, and there's been a ton of "project focused" activity that left giant messes that have taken other people years to grapple with - hugepages and memcg being the big ones. Swap's been a mess, compaction frequently pops up as a likely culprit in heisenbugs that aren't getting resolved - oh, and I see a lot of bug reports where zram is implicated (so again, who's responsible? distros are turning this stuff on, but it's not stable).
My biggest pet peeves have just been getting sufficient introspection to debug e.g. reclaim issues resulting in a lot of nitpicky infighting; we can't debug issues when we can't see what's going on, and yet high level maintainers dismiss any movement as "that'll make the logs too spammy". Ouch. And again, lack of anyone with a clear long term proactive vision and responsibility.
Posted Feb 16, 2025 10:55 UTC (Sun)
by sammythesnake (guest, #17693)
[Link] (5 responses)
That is certainly something to be hoped for, and for some is a motivating consideration behind pushing R4L, even a stated aim, but I think the far stronger motivation is the fact that Rust has very definite advantages over C as a language to implement kernel functionality in.
IMVHO (as somebody who has written zero Rust code, zero Kernel code, and maybe 150 lines of C code ever, "VH" gets some emphasis here!) I see so many reasons *not* to use C when there's any alternative that I'm frankly perplexed at the resistance some have to Rust.
Rust certainly has imperfections (as a bystander, even I can name a few) but anything that makes whole classes of bugs all but impossible is a no-brainer to me without something *major* to push back the other way.
The current controversy saddens me greatly - the R4L people aren't asking the current maintainer to do anything extra to support their work, and yet he's applying a veto on the basis that he doesn't want to do extra work. Frustrating indeed.
It seems to me that the correct way to manage this is for the R4L wrappers to go into mainline via a separate tree that Linus can pull from without other subsystem maintainers having to worry about them at all. In an ideal world, people working on the C code these wrappers talk to would cooperate and maybe even assist, but at the very least they shouldn't use their position to mess up stuff that doesn't hurt them.
There seems value here to the maxim "Lead, follow, or get out of the way"...
Posted Feb 16, 2025 13:23 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (4 responses)
As for rust in general, there's a number of reason to still be using C now:
* can build and run for a lot more devices
Posted Feb 16, 2025 19:05 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (3 responses)
Arguably it's not.
It just looks easier. C definitely has fewer syntax rules and fewer restrictions than Rust.
The problem is that those rules and restrictions *do* exist in (kernel) C, it's just that the compiler doesn't help enforce them, let alone emit helpful (no scare quotes – Rust is reasonably good in that regard) error messages.
Instead you get to learn the rules by experience and/or reading the sources of whatever code you call, code review that hopefully finds some of the more egregious problems, debugging crashed kernels, followup patches that fix your mistakes, and so on.
Speaking of code review. There's only so much mental bandwidth. Making sure that the code in question obeys the locking rules du jour, doesn't have use-after-free problems, and so on, means less focus on the actual logic.
Posted Feb 17, 2025 6:09 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
The awkward moment when you reply before reading what you're replying to, and you miss the line: "As for rust in general, there's a number of reason to still be using C now:".
You're basically arguing that python is harder because it has more hidden gotchas.
Is assembly easy since it's completely explicit then? Should we be using assembly directly? Should you have read my comment before replying to it?
(for me it's no, no, yes)
Posted Feb 17, 2025 7:38 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
For the record, I didn't miss that line at all. I merely disagree, rather vehemently in fact, with your "C is easier" point. Because it definitely isn't. Not by the time you need to use nontrivial interfaces … like the rest of the Linux kernel, which I assume is still the context of this discussion.
C (and even more so, assembly) is not at all explicit in the sense that the interfaces to existing code are full of implied assumptions you need to adhere to, otherwise your code is buggy and will crash on you (or randomly corrupt your users' RAM, who knows). By contrast, in well-written Rust interfaces most of those cannot-be-stated-in-C-much-less-assembler assumptions are right there and the *compiler* will *tell* you if you violate them.
Posted Feb 17, 2025 8:12 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
You keep talking about kernel and it was referred to user space. Since I even spoke about distributing and dependencies, which are very different on the kernel… That's because the comment I was replying to was wondering why would anyone still use C in general.
Posted Jan 31, 2025 13:47 UTC (Fri)
by dberlin (subscriber, #24694)
[Link] (1 responses)
You keep saying this and it's totally wrong.
The current state is that C maintainers are 100% free to ignore any and all breakages in rust they cause or that get caused. They do not have to learn it, build it, or care about it.
So they do not have to learn anything.
That may not be true some day, but it is true now, and has been very explicit.
Can we move on to some other argument?
Posted Jan 31, 2025 15:39 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link]
Posted Feb 4, 2025 6:10 UTC (Tue)
by roc (subscriber, #30627)
[Link] (65 responses)
It might take a month or two of focused work to learn Rust well enough to do tricky stuff well, like design clever APIs that statically enforce complex properties, or write tricky unsafe code. But it shouldn't take more than a few days to get to the point of being able to understand what most Rust code is doing and make modest changes to that code --- if you're an experienced software developer to start with. When I started writing Rust code back in 2016, I just started banging away writing code to read rr traces and was productive immediately. That code is still in production today.
There's a great fear of Rust code from some kernel developers, but lots of kernel stuff looks harder to me, the LKMM for example. The idea that someone with the skills to be a kernel developer needs months of study before they can be useful with Rust is very far-fetched.
Posted Feb 4, 2025 7:14 UTC (Tue)
by mb (subscriber, #50428)
[Link] (3 responses)
Posted Feb 7, 2025 10:49 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (2 responses)
The main issue people from other languages seem to have is that they see the compiler as an adversary to be defeated rather than an aide to help them. That is probably due to most other languages having horrible compiler error messages.
Posted Feb 7, 2025 16:48 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Feb 10, 2025 9:49 UTC (Mon)
by taladar (subscriber, #68407)
[Link]
Posted Feb 4, 2025 7:14 UTC (Tue)
by liw (subscriber, #6379)
[Link] (60 responses)
Rust is a large language and it has many concepts, some of which are far from the C language and some other current mainstream languages. However, the concepts are mostly orthogonal to each other and you can mostly learn Rust piecemeal, one part at a time.
Posted Feb 4, 2025 16:29 UTC (Tue)
by Trainninny (guest, #175745)
[Link] (59 responses)
https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
The lack of more than one major compiler also worries me. Especially since the borrow checker and solver in the Rust compiler, while impressive, are also very complex, arguably making it more difficult to implement a compiler for Rust. One example of the complexity of the type system checking in Rust is the work on the current and the new solver/type system for Rust.
https://github.com/lcnr/solver-woes/issues/1
>Even worse, there may be changes to asymptotic complexity of some part of the trait system. This can cause crates which start to compile fine due to the stabilization of the new solver to hang after regressing the complexity again. This is already an issue of the current type system. For example rust-lang/rust#75443 caused hangs (rust-lang/rust#75992), was reverted in rust-lang/rust#78410, then landed again after fixing these regressions in rust-lang/rust#100980 which caused yet another hang (rust-lang/rust#103423), causing it to be reverted yet again in rust-lang/rust#103509.
Posted Feb 4, 2025 18:41 UTC (Tue)
by liw (subscriber, #6379)
[Link] (58 responses)
Posted Feb 4, 2025 20:18 UTC (Tue)
by Trainninny (guest, #175745)
[Link] (57 responses)
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
>Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
If Rust in the Linux kernel will require a lot of unsafe, and unsafe is harder than C, will Rust in practice for the Linux kernel be significantly less memory safe than C?
On the other hand, Rust has pattern matching and disjoint unions, and more modern features from contemporary language design and functional programming, and some of the same advantages that C++ has, except with a way better build and package system than C++, ignoring dynamic linking.
Posted Feb 4, 2025 20:38 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
The `unsafe` in that driver is used for actual hardware interaction (reading registers, etc.). Linux Rust already has "safe" wrappers for almost all of them, so this driver can be rewritten in safe Rust. Once the DMA abstraction lands.
Posted Feb 4, 2025 21:28 UTC (Tue)
by Trainninny (guest, #175745)
[Link] (9 responses)
Posted Feb 4, 2025 23:27 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
More complicated drivers will have some unsafe code. Asahi Lina's DRM driver is probably a good approximation for it: https://github.com/AsahiLinux/linux/tree/gpu/rust-wip/dri...
Posted Feb 5, 2025 2:07 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (7 responses)
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
>Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
Anyone developing or maintaining those files may have to have a very good understanding of unsafe, or at least good enough to know what parts of the code outside the unsafe blocks can affect the correctness of the unsafe blocks. Are there other options for learning unsafe outside of Rustonomicon or blog posts?
If unsafe in that folder tree had been confined to one or two files, in its own small module, it might have been nicer.
Posted Feb 5, 2025 3:49 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
No. As long as `unsafe` blocks uphold the invariants, they are safe globally. And if you violate invariants inside the `unsafe` blocks, then the effect goes far beyond the module.
Posted Feb 5, 2025 4:12 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (3 responses)
Is that consistent with the following?
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
>Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
Basically, the code in the unsafe block relies on code outside the unsafe block being correct in some regards to be memory safe/not have undefined behavior. And thus requiring vetting of much more than the unsafe block.
Did I misunderstand the Rustonomicon? Or is the Rustonomicon wrong here?
Posted Feb 5, 2025 5:29 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Feb 5, 2025 5:36 UTC (Wed)
by Trainninny (guest, #175745)
[Link]
1: If you have a module with some unsafe code in it, and whether that unsafe code is memory safe/has no undefined behavior, or not, relies on code outside that unsafe block, for instance mutable state;
2: And that mutable state's visibility has been limited to the module;
3: Then it is only the module that needs to be vetted.
This can still be a lot more code that needs to be vetted than just the unsafe block, but at least not more than outside the module, due to usage of visibility.
Posted Feb 5, 2025 9:46 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
The canonical example of this is alloc::vec::Vec; safe code inside the alloc::raw_vec and alloc::vec modules can break safety guarantees (you can inline Vec::set_len to safe code in alloc::vec, for example, which breaks invariants that unsafe code depends upon). But this is considered acceptable (despite the unsafe code being unsound if the safe code breaks the invariant), because all of the code that can break the invariants must, definitionally, be in the same module as the unsafe code that depends on those invariants holding.
Posted Feb 7, 2025 0:31 UTC (Fri)
by moltonel (guest, #45207)
[Link] (1 responses)
You shouldn't worry too much about the use of unsafe in kernel code: it's a small number of lines that need closer scrutiny, but it's not that hard. Writing that driver in C would have been much more error-prone.
Posted Feb 7, 2025 8:09 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Bottom line: Rust wins. And frankly the proof is right there, because given the complexity of what she and her collaborators have to work with, IMHO she couldn't have done the job with C (and neither could anybody else). No way nohow. Not with that amount of features *and* stability.
Posted Feb 4, 2025 23:41 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (45 responses)
I think that's a misunderstanding of what Rust unsafe is. In C and C++, it's incredibly easy to write unsafe code without even realising it. So of course, Rust unsafe is harder than C or C++, C and C++ will let you do stupid things without a warning, Rust will barf.
Rust will almost certainly be safer because (a) if safe code is unsafe in practice, that's a compiler bug. And (b) if you're using "unsafe", that's an explicit choice, and if you *know* you're using "dangerous" code you're going to be careful. If you don't realise you're holding a footgun, you'll probably set it off!
Cheers,
Posted Feb 5, 2025 1:06 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Also it's worth noting that while writing That means that “effort per line of
Posted Feb 5, 2025 2:15 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (42 responses)
Are you sure?
chadaustin.me/2024/10/intrusive-linked-list-in-rust/
>Unsafe Rust Is Harder Than C
Posted Feb 5, 2025 9:39 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (23 responses)
So Rust provides the tools to prove that some code is safe. THAT IS THE POINT.
90% of your rust code is safe because the compiler can mathematically prove (absent cosmic rays, voltage glitches, all the things that plague real life) that the MATHS DOES WHAT IT SAYS ON THE TIN.
Only a little bit of code (written by - hopefully expert - programmers) uses "unsafe", where the PROGRAMMER has to prove it's not going to go wrong.
It's the difference between maths and science - in maths you prove something is logically correct. Rust can do that, and any code which passes is "safe". In science, " "the exception proves the rule" is wrong" - an unsafe block is where a programmer asserts "we've tried to break it every which way and failed". How can you prove you're not going to get random cosmic ray bit-flip? How can you prove somebody's not going to turn on a motor next to your data cable and screw everything up before it gets to your UART? YOU CAN'T.
It's only the idiots who think that a program, once proven correct, is going to work perfectly who believe rubbish like that. 90% of code CAN be proven TO WORK. The problem is the 10% which, while it can be proven to be well-formed, cannot be proven to work in the presence of real-life interference. THAT is where Rust's "unsafe" lives, and THAT is why C and C++ are so dangerous. They fool you into thinking that well formed code will always work, because 90% of the time it does!
(Rust's unsafe is also where code lives which *we* can prove correct, but the compiler *can't*. So it's much more likely to be buggy.)
Cheers,
Posted Feb 5, 2025 10:27 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (13 responses)
>Only a little bit of code (written by - hopefully expert - programmers) uses "unsafe", where the PROGRAMMER has to prove it's not going to go wrong.
If Rust code in the Linux kernel will on average have a large proportion of unsafe, and possibly be present in most or all files and modules, does that mean that anyone touching Rust code in the Linux kernel will have to be experts at Rust?
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
>Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
I do not understand why you are using all-caps so much.
Posted Feb 5, 2025 11:51 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (9 responses)
Yes - because by definition you are playing with code that contains reality, corner cases, hard mathematical problems.
Which makes Rust (in general) much easier/safer than C/C++, because most programmers don't (have to) go near that stuff - it's safely walled off in clearly marked danger zones.
> I do not understand why you are using all-caps so much.
Because I gather the standard way of emphasizing stuff is italics, and I don't do html :-) As other people have noticed, I can get a bit emphatic at times. (I'm a dinosaur that's been around the block a few times.)
Cheers,
Posted Feb 5, 2025 13:20 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
All-caps doesn't read like emphasis. It reads like purple-ink crankery. Emphasis has long been done like *this*.
Posted Feb 5, 2025 14:35 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
It probably doesn't help (I did say I was a dinosaur) that when I cut my teeth, lower case was an add-on and most of the terminals I used didn't have it ... :-) So I'm probably much less sensitive to it than other people.
Cheers,
Posted Feb 5, 2025 17:40 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (6 responses)
Are you sure?
youtube.com/watch?v=DG-VLezRkYQ
>@oconnor663 11 months ago It could've been thirty seconds:
chadaustin.me/2024/10/intrusive-linked-list-in-rust/
>Unsafe Rust Is Harder Than C
https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
>I made the case on Twitter a few days ago that writing unsafe Rust is harder than C or C++, so I figured it might be good to explain what I mean by that.
Some of this argues that part of the motivation for the high difficulty of writing unsafe is enabling the compiler to do optimizations. Others of it appears to argue that the increased difficulty of unsafe Rust is accidental, and that work should be done to make it easier. And that C and C++ are easier to reason about than unsafe. A problem even appears to be a lack of teaching material, specification, etc. for unsafe, Rust memory model, etc. And there are holes in the Rust type system, causing practical problems, and the Rust language developers are working on a new type system and solver. This latter issue may make it harder to implement another Rust compiler.
Posted Feb 5, 2025 18:01 UTC (Wed)
by corbet (editor, #1)
[Link] (5 responses)
Posted Feb 5, 2025 18:42 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (4 responses)
I do claim that I am putting effort into my comments. For instance, in https://lwn.net/Articles/1008103/ , I put effort into discussing programming language design.
If you are referring to the holes in Rust's type system, there are several examples of that and associated problems, discussions, mitigations and fixes.
github.com/rust-lang/rust/issues/25860
github.com/rust-lang/types-team/issues/117
blog.rust-lang.org/inside-rust/2023/07/17/trait-system-refactor-initiative.html
github.com/rust-lang/rust/issues/25860#issuecomment-1455898550
github.com/orgs/rust-lang/projects/44/views/1
github.com/rust-lang/rust/issues/75313#issuecomment-672216146
github.com/rust-lang/rust/pull/75443
github.com/rust-lang/rust/issues/75992
github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22A-type-system%22
github.com/rust-lang/rust/issues/129844
github.com/rust-lang/rust/issues/25860#issuecomment-1579067138
Rust has an advanced solver and type system checker, but it is also very complex, and the Rust language developers are working on a new solver and type system and trying to make it as backwards compatible as possible.
What should I do in regards to this discussion? Are my comments off-topic? Too long? Something else?
Posted Feb 5, 2025 19:13 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 5, 2025 20:02 UTC (Wed)
by Trainninny (guest, #175745)
[Link]
Posted Feb 5, 2025 20:01 UTC (Wed)
by daroc (editor, #160859)
[Link]
There's nothing wrong with long, detailed technical comments. One of the things that I love about the LWN comment section is that we will occasionally get real experts coming in and writing detailed responses to stuff. That's also why the comment submission form has no maximum length.
But valuable comments are usually written to directly address the comments or articles they're responding to — something that just inserting long quotes or lists of links to other resources pretty much cannot do. After all, you're responding to something written after the source you're quoting, in most cases.
Instead of quoting large sections of text, it is usually better to say something along the lines of "I disagree with [specific point X] because of [specific reason Y, stated in your own words]. In support of that, [here is a brief and narrowly targeted quote on the topic]."
Generally, when we say that comments should be "informative", that means they should be both information dense, and presented in a way that makes people more informed. Ideally, someone should be able to come to your comment, read it, and feel like they understand more than they did before. If they bounce off because of a lengthy quote, or because you're not responding directly to their previous points, that makes your comment less valuable even if the topic is otherwise interesting.
Posted Feb 5, 2025 21:51 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And this has exactly what to do with the price of tea in China?
Rust developers are writing theorem provers so they can move code out of "unsafe" into "safe". Are you saying they shouldn't be doing that?
That is why you're seen as trolling. You're treating other peoples' attempts to improve the language - which is what Rust expects of its developers - as evidence that Rust is not fit for purpose.
Cheers,
Posted Feb 5, 2025 16:09 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (2 responses)
That's a rather big "if" right there. I would assume that the goal is for the average kernel driver to not require *any* unsafe Rust. Otherwise what'd be the point?
Posted Feb 5, 2025 17:44 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (1 responses)
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
>Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
Posted Feb 6, 2025 23:14 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link]
Other modules may talk to the hardware more and would be chock full of unsafe, granted. But if the high-level code is isolated from them, that's already a lot that the compiler can guarantee.
Posted Feb 5, 2025 17:04 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (7 responses)
"The exception proves the rule" does *not* mean that the exception *to* the rule proves that the rule is correct (because in that case it's falsified and thus by definition incorrect).
The sentence means: you need to *test* with exception[al condition]s to prove that the rule holds.
Posted Feb 5, 2025 18:47 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (6 responses)
btw, why do you need to test with *exceptional* conditions? Most rules are proven false with near as dammit no effort whatsoever (other than tearing you hair out over idiots who write off counter-examples as anecdata ...)
Cheers,
Posted Feb 6, 2025 8:47 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (5 responses)
It's perfectly true *if* you understand what it's actually trying to say, instead of interpreting the sentence as "the fact that the rule doesn't apply under this-or-that exception tells us that the rule itself is correct", which of course is nonsense.
In other words, your idea that in this context "exception" and "prove" means what you think it does is false.
Posted Feb 6, 2025 10:50 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (4 responses)
Therefore the exception does prove the rule - it proves the theory is wrong. Which is what I've been saying all along.
And yes, your example of people claiming that the exception validates the rule is very common - and completely wrong! Just don't blame me for saying that! It winds me up no end.
Cheers,
Posted Feb 6, 2025 10:59 UTC (Thu)
by euclidian (subscriber, #145308)
[Link]
"The fact that this case is called out as exceptional demonstrates the rule holds in general."
Ie if your argument against a *general* rule is a very contrived case it is an argument that the rule (while not holding in all cases) is a good default starting point.
I agree as a logic statement it is nonsense.
Posted Feb 6, 2025 12:58 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (2 responses)
*Sigh* That was exactly my point: the original meaning of the sentence uses this word in a completely different sense. Think "exceptional input", not "demonstrating-that-the-rule-is-false output".
Posted Feb 6, 2025 14:41 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
I just look at it as a scientist. One contradictory result and your theory is toast. That is the sole meaning that makes sense to me. (Except, as stated before, where people use it to argue tautologiously.)
Cheers,
Posted Feb 7, 2025 14:40 UTC (Fri)
by foom (subscriber, #14868)
[Link]
So, go ahead and keep using it in those ways if you wish, but, please do be aware the above is the meaning intended by the vast majority of English speakers using this phrase—and it's not "nonsense" to use it in that way.
Posted Feb 6, 2025 13:31 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Can we, please, stop using that phrase? Because it become just a clever phrase that doesn't mean anything anymore (or, rather, it may mean four or ten, or maybe twenty different things depending on who says it). Original exceptio probat regulam in casibus non exceptis was pretty clean and unambiguous: if you are investigating what have happened in a certain incident and find out phrase “Special leave is given for men to be out of barracks tonight till 11.00 p.m.” recorded in the books on a big holiday… then you can be reasonably sure that there are a certain rule that forbids staying after 11.00 p.m normally and only “on special occasion” it can be safely violated if you have explicit permission – and we can be reasonably sure that rule was there even if books where said rule was originally written haven't survived. Simple and easy. But when people started using that phrase outside of that context… it started having bazillion different meanings and today… very few know where have it come from and what it does even mean… everyone ascribes the meaning that their imagination gives them (Wikipedia lists four meanings, but I'm sure there are more) and so use of it causes more confusion than revelation.
Posted Feb 5, 2025 10:14 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (17 responses)
Aliasing rules are good example: all the C compilers I can find apply a conservative interpretation of the type-based aliasing rules that C uses (assuming you don't turn them off completely with -fno-strict-aliasing or equivalent), because there's enough code out there that almost complies, but not quite, that compilers have to extend the rules with extras to be able to compile enough extant code to be useful. In contrast, Rust's aliasing rules are enforced strictly on users, and if you break them in a controlled and small manner (like you can get away with using a C compiler), Rust will "simply" give itself permission to miscompile your code later.
The result is that unsafe Rust, while theoretically no harder than normal C, is practically harder because Rust is much less forgiving of you breaking the rules of unsafe than C compilers are of you breaking the rules of C.
Posted Feb 5, 2025 10:42 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (16 responses)
https://kristerw.blogspot.com/2017/09/why-undefined-behav...
C and C++ compilers cannot be assumed to be "less forgiving". Undefined behavior is undefined behavior, whether in C, C++, or Rust.
Posted Feb 5, 2025 10:47 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (15 responses)
UB is thus not the same between compilers, and Rust's compiler is one of the strictest for actually exploiting UB to optimize, where C and C++ compilers don't because they would be useless if they enforced a strict reading of the C Standard.
Posted Feb 5, 2025 11:05 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (11 responses)
Posted Feb 5, 2025 11:50 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (8 responses)
I'm saying that the Rust compiler hews much closer to the (informal) Rust standard than C compilers do - there's a lot of C out there that has UB in ISO Standard C, but does not contain UB in GCC C (sometimes requiring -fno-strict-aliasing or -fwrapv to define the UB the way the code requires). Writing code that has no UB in ISO Standard C is about as complex as writing unsafe Rust, but C as it's generally talked about is not strictly ISO Standard C, but instead things like GCC C, and Clang C, and Microsoft Visual C.
Posted Feb 5, 2025 17:21 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (7 responses)
>I'm saying that the Rust compiler hews much closer to the (informal) Rust standard
Are there holes in the Rust type system, and do these give trouble in practice? Are the Rust language developers working on a new type system and solver for Rust, and trying to make it as backwards compatible as possible?
https://github.com/lcnr/solver-woes/issues/1
>Even worse, there may be changes to asymptotic complexity of some part of the trait system. This can cause crates which start to compile fine due to the stabilization of the new solver to hang after regressing the complexity again. This is already an issue of the current type system. For example rust-lang/rust#75443 caused hangs (rust-lang/rust#75992), was reverted in rust-lang/rust#78410, then landed again after fixing these regressions in rust-lang/rust#100980 which caused yet another hang (rust-lang/rust#103423), causing it to be reverted yet again in rust-lang/rust#103509.
How well defined is Rust, unsafe, the memory model of Rust? How easy is it to tell for a programmer whether a given piece of unsafe Rust code has undefined behavior or not? How much material, and what material, does a Rust programmer need to study, to be able to develop and maintain unsafe Rust with a high level of confidence?
chadaustin.me/2024/10/intrusive-linked-list-in-rust/
>Unsafe Rust Is Harder Than C
https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
>I made the case on Twitter a few days ago that writing unsafe Rust is harder than C or C++, so I figured it might be good to explain what I mean by that.
youtube.com/watch?v=DG-VLezRkYQ
>@oconnor663 11 months ago It could've been thirty seconds:
Posted Feb 5, 2025 18:47 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
My fundamental argument is that practically Rust is harder than C, while theoretically C is as hard as Rust, because Rust doesn't give you "dialects" - there is one and only one version of Rust, and while Rust may eventually weaken the constraints unsafe code has to follow, for now the only way to be guaranteed safe is to comply with all the constraints.
However, if you try to write ISO Standard C, it's as hard (if not harder) to comply with the rules - the only way to be guaranteed safe is to obey all the constraints ISO Standard C imposes (for which there are no tools to check that you've done this - it's a pure whiteboard exercise, unlike Rust, where there's things like Miri to help). Worse, there are constraints in the ISO spec where no extant compiler currently exploits the fact that ISO Standard C leaves this area underspecified, because doing so would break too much code and get rid of your user.
With practical C, though, you don't write ISO Standard C; you write GCC C, or Microsoft Visual C, or Clang C, which have laxer restrictions than the ISO Standard, and has tooling like UBSAN to detect breaches of the compiler-dialect C rules. That's an easier task than writing ISO Standard C that's fully compliant with the rules, and also easier than writing Rust that's fully compliant with the Rust rules, because each compiler defines some behaviours that ISO leaves as undefined, unspecified, or implementation-defined (and in the last case, it's required to define them by ISO rules, and can't leave them alone).
And, on top of that, it's possible to use compiler switches to ask for a C dialect with certain things that are technically UB in ISO Standard C defined by the compiler in a way that's useful - -fno-strict-aliasing, -fwrapv for two examples. Writing safe code in those dialects is easier, because there's less room to accidentally write UB to begin with.
Posted Feb 5, 2025 19:55 UTC (Wed)
by Trainninny (guest, #175745)
[Link]
>Your wall of text does not back your claim that my argument is wrong - indeed, it doesn't even address it at all.
I am very, very sorry, but you are completely wrong about this.
>[...] because Rust doesn't give you "dialects" - there is one and only one version of Rust, [...]
This is also completely wrong, though it is not core to the argument. Several counter-examples:
https://doc.rust-lang.org/cargo/reference/profiles.html#p...
panic="unwind"/"abort"
https://github.com/rust-lang/rust/issues/126683
-Zoom=panic/abort
https://doc.rust-lang.org/nightly/edition-guide/rust-2024...
Whether the Rust code in that page deadlocks or not depends on its edition. Rust does at least have automatic migration tools, but there are still drawbacks to this: You cannot in general tell without knowing the specific Rust edition what a sample of Rust code does; and documentation, guides, tutorials, etc. that do not explicitly mention the edition that they are valid for, will risk having ambiguous meaning and correctness.
You can then argue that the dialects of C or C++ in specific compilers are significantly worse, which I could imagine being true and is a drawback of those compilers and arguably a drawback of the C and C++ languages as well. But that is a different discussion, and Rust 100% does have dialects. Rust is also in a situation where it has 1 major compiler; would Rust end up with similar issues as C and C++ if it had multiple compilers? And having multiple major compilers are presumably a good thing overall for a language used for critical infrastructure.
>[...] the only way to be guaranteed safe is to obey all the constraints ISO Standard C imposes (for which there are no tools to check that you've done this - it's a pure whiteboard exercise, unlike Rust, where there's things like Miri to help). [...]
This is also completely wrong, MIRI can be seen as a runtime checker/sanitizer with many of the same advantages and drawbacks, and there are many different sanitizers and runtime checkers for C as well as C++. Some of them are ported between C++ and Rust. And MIRI, while greatly helpful, is not perfect. People have complained about bugs in MIRI, about false positives and false negatives, and as a runtime checker/sanitizer, MIRI takes a long time to run like C++ sanitizers also do. And like sanitizers, if your test run with MIRI does not cover a specific combination of control flow and values, MIRI will not check that.
>With practical C, though, you don't write ISO Standard C; you write GCC C, or Microsoft Visual C, or Clang C, which have laxer restrictions than the ISO Standard, and has tooling like UBSAN to detect breaches of the compiler-dialect C rules. That's an easier task than writing ISO Standard C that's fully compliant with the rules, and also easier than writing Rust that's fully compliant with the Rust rules, because each compiler defines some behaviours that ISO leaves as undefined, unspecified, or implementation-defined (and in the last case, it's required to define them by ISO rules, and can't leave them alone).
This is again not relevant as far as I can tell. But, the situation for Rust is worse, since Rust does not have a specification, and also does not have a specification for its memory model, and also only has one main compiler. A specification for Rust is currently a work in progress. C++ and C has several major compilers for them, despite flaws, and some codebases do try to work with any major compiler. I agree that this is a weakness of both C and C++, more so for C++ given increased complexity. But Rust is arguably and unfortunately worse here, which is highly regrettable, given that Rust is much younger. A major reason for Rust being worse here is as far as I can tell the type system of Rust being both complex and having holes. The Rust language developers are working on a new solver and type system for Rust, but it is an effort that is taking many specialized developers years.
One practical consequence of the type system holes of Rust, apart from the issues encountered for maintenance of the language and main compiler and the issues for users like exponential regressions in compile times, is that writing a new compiler may be difficult. Unless you copy-paste the solver of the main Rust compiler, despite that solver having issues.
There are also complaints that the rules of unsafe for Rust has changed and become more complex over time, which I hope as of 2025 are no longer true. It would be very good if unsafe Rust becomes easier, not harder, as the language is developed. But there have been complaints about the opposite happening in the past.
That Rust does not have a specification, and has only one major compiler, also makes it easier for implementation-defined behavior to accidentally become part of the language. https://github.com/rust-lang/rust/issues/97146 tells of some users apparently relying on a specific behavior related to double panics.
Once the new type system and solver for Rust is ready, it may end up not being 100% backwards compatible with the old type system.
Posted Feb 5, 2025 19:28 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (4 responses)
And now you are really coming over as lying by omission. Sorry.
Let's take an example of electric cars. Pretend I have an electric car with a range of 250 miles, and it takes a day to give it a full charge. How long will it take me to drive 400 miles from London to Edinburgh? A day and a half? No. At 50 mph it will take me about 9 hours.
Because charging an electric car follows the 80/20 rule. If I go half way (preferably a bit more) it will take about 4 hours. Stop for a coffee in a service station, and that is enough to charge the car to about 80%. And that's enough to cover the remaining 200 miles. I might have to stop a second time, but I might not.
The two crucial facts about Rust, is that (a) all "safe" code has been proven correct by the compiler, and (b) the majority of Rust programmers should never have to touch unsafe code.
Maybe you're right banging on about all these exceptions, and the Rust guys are writing all this fancy stuff like MIRI, but the definition of "unsafe code" is "stuff the compiler can't prove is correct". So all you're doing is like climate deniers complaining electric cars are useless because it takes too long to get those last few miles into the battery.
The definition of "unsafe" code is "stuff the compiler can't prove correct". And you're moaning that the compiler writers aren't mathematical gods because they can't (yet) prove some very tricky problems. And other problems are just plain insolvable.
THAT is why unsafe code is hard. Because the maths behind it is hard. Knuth ranks his problems from 0 is "easy" to (iirc) 5 is "if you can solve it it's worth a PhD". As soon as you start programming "unsafe", you are dealing with code where the proofs are 4 or 5 on the scale - if it's even provable!
90% of Rust programmers are unlikely to step outside the safe zone in their entire career. All safe code MUST be fully defined, and MUST be provably correct (bugs, cockups, and acts of God excepted).
100% of C/C++ programmers are likely to step on an unsafe landmine several times a year.
That's a big difference!
Cheers,
Posted Feb 5, 2025 19:50 UTC (Wed)
by corbet (editor, #1)
[Link] (1 responses)
Wol why do we have to keep asking you this?
Posted Feb 5, 2025 20:03 UTC (Wed)
by Trainninny (guest, #175745)
[Link]
Posted Feb 5, 2025 20:33 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (1 responses)
Is that not in direct contrast to https://lwn.net/Articles/1007973/ ? At least in the context of the Linux kernel?
>[...]but the definition of "unsafe code" is "stuff the compiler can't prove is correct"[...]
A minor technicality: the compiler is not proving the correctness of the code, it is (meant to be) proving the memory safety/absence of undefined behavior. In the sense that memory safe code without undefined behavior can have logic bugs.
>All safe code MUST be fully defined, and MUST be provably correct (bugs, cockups, and acts of God excepted).
Did you mean unsafe?
But even then, this does not always hold in practice.
github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259
cve.org/CVERecord?id=CVE-2024-27308
>100% of C/C++ programmers are likely to step on an unsafe landmine several times a year.
I do not believe this is true, but I do believe that Rust makes some aspects significantly easier, and not only its borrow checking and solver and lifetimes handling, though in the specific case of Rust that also comes with penalties in the unsafe subset. One great advantage is Rust's pattern matching and disjoint unions, taken from functional programming. And one thing that makes C and C++ error prone for some cases is that C and C++ are ancient languages that have a lot of cruft and baggage. I do prefer functional programming, and hope that C++ will get a good and robust implementation of both pattern matching and disjoint unions (C arguably has a limited scope), but Rust has significant issues. To be perfectly frank, I wonder if a Rust killer in the future may greatly iterate on and improve and be closer to what many of us hoped that Rust would be.
>The definition of "unsafe" code is "stuff the compiler can't prove correct". And you're moaning that the compiler writers aren't mathematical gods because they can't (yet) prove some very tricky problems. And other problems are just plain insolvable.
But these issues are not purely theoretical, and appears to cause not only users but also language developers trouble.
https://github.com/lcnr/solver-woes/issues/1
>Even worse, there may be changes to asymptotic complexity of some part of the trait system. This can cause crates which start to compile fine due to the stabilization of the new solver to hang after regressing the complexity again. This is already an issue of the current type system. For example rust-lang/rust#75443 caused hangs (rust-lang/rust#75992), was reverted in rust-lang/rust#78410, then landed again after fixing these regressions in rust-lang/rust#100980 which caused yet another hang (rust-lang/rust#103423), causing it to be reverted yet again in rust-lang/rust#103509.
And the Rust language developers made multiple blog posts discussing their work on the new solver, and on trying to make it backwards compatible.
There is a comment where I discuss the language design of Rust and related issues https://lwn.net/Articles/1008103/ . One could argue that requiring a complex solver, that in practice may end up with holes, has practical trade-offs in the language design. I recall that Bjarne Stroustrup was against any language feature that would require complex solvers. I wonder if part of the reasoning is that it would make it harder to implement correct compilers. Which may be consistent with some of the headaches that some apparently really skilled people among the Rust language developers appear to be dealing with. I do not envy their position, their challenge looks difficult.
>And now you are really coming over as lying by omission. Sorry.
I do not agree with this at all, and as far as I can tell, you are completely wrong about this.
Posted Feb 5, 2025 20:36 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Feb 5, 2025 12:15 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Maths is the art of contriving a logically consistent imaginary world.
Science is the art of finding a logical world that *appears* to describe the real world.
C/C++ - as farnz said, tries to live in both worlds, and much UB is actually defined outside of the standard - I believe the standard even says as much! (Cue the circular argument between the C standard and Posix, where both try to defer to the other).
Rust actively tries to split the two apart, so unsafe Rust is - by definition - hard. It's science and there's no guarantee whatsoever that you're going to get the result you expect.
The problem with C/C++ is it's a chimera, and you're quite likely to trip over UB where you least expect it. Rust defines that as a compiler bug.
So Rust - as a whole - is much easier than C/C++, but that's because all the dangerous stuff is walled away behind "unsafe".
Oh - and as for the comment that "the kernel will contain a lot of unsafe code", (a) I get the impression that's unlikely, and (b) it's a massive improvement on the current state of affairs because if large chunks of the kernel are clearly marked "here be dragons", at least we know where to watch out where we're going.
Cheers,
Posted Feb 5, 2025 18:25 UTC (Wed)
by Trainninny (guest, #175745)
[Link]
The programming language design theory of splitting a language into a not unsafe and an unsafe part ("not unsafe" as in lacking undefined behavior), and also try to make it run fast, is a large topic of discussion, with many ways of going about it, with many different trade-offs and different attempts. It is not clear to me whether in this design space, with a split and with performance requirements, that a programming language with these requirements will necessarily have its unsafe be harder than C and C++. If a language design with such a split will necessarily have its unsafe subset be harder, then that could be seen as an argument against the whole approach of having an unsafe split. Also because making hard code even harder than it has to be, is not great - is that really worth what you may gain in return?
But, whether or not all that holds, Rust has at the very least a number of properties making it substantially harder to write unsafe, that are in theory independent of this split. An example is the lack of a specification of Rust, the specification is a work in progress. Another are the holes in Rust's type system, and the Rust language developers are working on a new type system and main compiler solver for Rust, and trying to make it as backwards compatible as possible. Having holes in a type system is independent of having an unsafe split.
https://github.com/lcnr/solver-woes/issues/1
>Even worse, there may be changes to asymptotic complexity of some part of the trait system. This can cause crates which start to compile fine due to the stabilization of the new solver to hang after regressing the complexity again. This is already an issue of the current type system. For example rust-lang/rust#75443 caused hangs (rust-lang/rust#75992), was reverted in rust-lang/rust#78410, then landed again after fixing these regressions in rust-lang/rust#100980 which caused yet another hang (rust-lang/rust#103423), causing it to be reverted yet again in rust-lang/rust#103509.
doc.rust-lang.org/nomicon/references.html
>Unfortunately, Rust hasn't actually defined its aliasing model.
The aliasing rules of Rust supposedly not being defined, is independent of and is not inherent to an unsafe split.
chadaustin.me/2024/10/intrusive-linked-list-in-rust/
>Unsafe Rust Is Harder Than C
And there are other factors making unsafe harder in Rust that are independent of the unsafe split. For instance, is there a lack of teaching material and documentation for learning unsafe? Is the Rustonomicon sufficient? What about how the rules for writing correct unsafe changes with new versions of Rust?
>Oh - and as for the comment that "the kernel will contain a lot of unsafe code", (a) I get the impression that's unlikely, and (b) it's a massive improvement on the current state of affairs because if large chunks of the kernel are clearly marked "here be dragons", at least we know where to watch out where we're going.
But what if most Rust code will require the careful vetting that unsafe requires?
https://lwn.net/Articles/1007973/
Posted Feb 5, 2025 11:44 UTC (Wed)
by excors (subscriber, #95769)
[Link] (2 responses)
Posted Feb 5, 2025 17:29 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (1 responses)
https://stackoverflow.com/questions/25664848/is-it-allowe...
For C:
>if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined
Posted Feb 5, 2025 18:34 UTC (Wed)
by excors (subscriber, #95769)
[Link]
Posted Feb 8, 2025 3:27 UTC (Sat)
by ssokolow (guest, #94568)
[Link]
Basically, that, no matter how hard you try with typecasting, the Previously, you had to use the non-obvious
Posted Jan 31, 2025 20:06 UTC (Fri)
by atai (subscriber, #10977)
[Link] (2 responses)
> So they can't be wrong?
A fundamental idea of existence, is that the host cells of the organism are the part of the life of the organism.
These people doing the current work on Linux are part of the host of Linux. They keep it alive.
If you come in and call the cells of the host cancer, then you are wrong. Foreign cells trying to come to a host cannot call existing host cells cancer. The foreign things may be cancer.
Posted Jan 31, 2025 20:10 UTC (Fri)
by dralley (subscriber, #143766)
[Link]
This analogy is bad, both literally and metaphorically.
Posted Jan 31, 2025 20:17 UTC (Fri)
by mb (subscriber, #50428)
[Link]
Please read what I actually wrote.
Get back to an actual technical discussion with actual arguments.
You may say that Rust is bad because it's complex.
We can discuss these things and assess to what degree they are relevant, right or wrong.
But calling it or its developers a "cancer" is not going to lead anywhere.
Posted Jan 30, 2025 20:59 UTC (Thu)
by dmv (subscriber, #168800)
[Link] (19 responses)
On the other hand, I cringed when I saw the request in the thread. It would’ve been much better to reach out privately to them to solicit their help/opinion. Doing it the way they did here raises the stakes in possibly counterproductive ways. If L/G step in, it incentivizes RfL running to mommy and daddy every time anyone pushes back, and it cuts against the distributed management model. If they don’t step in, they’re delivering a gut punch to the RfL people and signaling to other maintainers that firm enough resistance can make Rust go away.
Posted Jan 31, 2025 0:57 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Posted Jan 31, 2025 1:04 UTC (Fri)
by corbet (editor, #1)
[Link]
Posted Jan 31, 2025 9:59 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (16 responses)
Posted Jan 31, 2025 11:01 UTC (Fri)
by josh (subscriber, #17465)
[Link] (15 responses)
There are plenty of parts of the kernel many people don't want to work in; ask kernel maintainers how many of them would be enthusiastic about touching the tty layer.
This is an escalation, a maintainer trying to say he doesn't want Rust in the kernel, calling it a "cancer", and saying "I will do everything I can do to stop this". This is not a problem that can be solved by telling someone this is not going to make more work for them and they can ignore it, because they're not looking to ignore it, they're looking to destroy it.
Posted Jan 31, 2025 15:44 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (10 responses)
Posted Jan 31, 2025 16:42 UTC (Fri)
by dralley (subscriber, #143766)
[Link] (9 responses)
In the case with Wedson, the fact that a roomful of kernel developers argued without agreement for several minutes on the precise semantics of the existing C APIs is precisely evidence that such semantics need to be thoroughly documented - which was all the Rust developers were asking for. If it's so complex that the foremost experts in the world can't remember exactly how it works, then it's very hard to take seriously the opinion that "everything is fine, no need to write it down for posterity".
In the case with Asahi Lina, that was over code that was *broken* with or without Rust, the issues would have been visible even with a pure C driver, but the maintainer was rejecting her opinion on the basis of being a "Rust person talking about lifetime issues" despite this.
In both cases the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint.
Posted Feb 5, 2025 7:28 UTC (Wed)
by qtplatypus (subscriber, #132339)
[Link] (5 responses)
Posted Feb 5, 2025 9:46 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (4 responses)
Someone higher up stepped in, knocked their heads together, and said "we need to keep these two apart". Then everything got sorted.
Sometimes two people just don't get on. I've had people I can't stand. It happens. It got sorted.
Cheers,
Posted Feb 5, 2025 14:55 UTC (Wed)
by dralley (subscriber, #143766)
[Link] (3 responses)
Eventually she gave up and wrote her own scheduler in Rust to avoid having to deal with drm_sched.
Posted Feb 5, 2025 15:46 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
It's a long way from saying "but that is an obvious bug in the C code", to getting to "and this is a fix *that*will*not*cause*spaghetti*breakage*where*you*least*expect*it*". And THAT is what Lina just could not get!
I'm not going to come down on either side, but I've had plenty of experience of an "obvious" fix going subtly and disastrously wrong, so I can sympathise with the C guy. I'm dealing with this right now at work - a colleague didn't bother to understand the subtleties of some tricky code, put in a fix of her own that happened to work (breaking the overarching design of the original code), and now things have changed again we're having to bodge something, that should have been simple, to avoid breaking her code. All because what was meant to be a simple and clean - *and* *reversible* - design was bodged, and despite having forseen that we would want to back it out, we now can't because these bodges rely on it being present when it really should not be!
Cheers,
Posted Feb 5, 2025 15:52 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Yes the C code was broke - for ONE person. And if I know the design of the code, I will quite happily dig in and refactor *my* stuff. But as soon as I start digging in other peoples' code, I'm a lot more cautious.
Lina has a compiler that helps her and alerts her much more to potential screwups. The C guy gets precious little help from the compiler - he doesn't want to get burnt where a "simple" change compiles just fine (but wrong) and then blows up in someone *else's* face.
Cheers,
Posted Feb 5, 2025 21:26 UTC (Wed)
by dralley (subscriber, #143766)
[Link]
See her comments here and the ones from Christian she was directly responding to:
https://lore.kernel.org/lkml/7e53bc1f-7d1e-fb1c-be45-f03c...
And David Arlie dropping in on a second discussion thread w/ Christian and Lina (those comments also worth reading)
https://lore.kernel.org/lkml/CAPM=9txcC9+ZePA5onJxtQr+nBe...
Now, I'm not entirely unsympathetic with Christian. From the standpoint of how things currently are, there's quite a lot of code written around the broken core abstractions, and un-breaking those abstractions is a lot of work. But the problems she was hitting were real, they were acknowledged, and the existing scheduler was not in any way "simple" as you claim it to be - and it doesn't seem like there was much motivation to fix those things. Hence Lina deciding it wasn't worth the time investment.
Posted Feb 18, 2025 9:42 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (2 responses)
I respectfully disagree that these two cases can be classified the same like that.
The case with Asahi Lina was about technical issues[0]. Raising technical issues in proposed patches is the job of a maintainer. No DRM maintainer said anything like "I don't want Rust in the kernel" or "Rust is cancer".
[0] You're right that the same issues might have affected C patches, and they would have been raised the same way then. In fact, similar issues were raised in C patches many times before.
Posted Feb 19, 2025 10:27 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (1 responses)
Yeah, well, that's the point: the case *was* about technical issues, those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.
But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.
Posted Feb 19, 2025 13:53 UTC (Wed)
by daenzer (subscriber, #7050)
[Link]
The text you quoted from my previous comment was in response to "the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint". If a maintainer raising technical issues in patches is "difficult to make sense of from a purely-technical standpoint", maintainers might as well pack up and go shopping.
> those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.
Don't think they really "uncovered" anything, the maintainer was already aware of the issues and explained them to the patch author.
> But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.
Having witnessed that discussion first-hand, I disagree that the maintainer refused to engage with the patch author. There was clearly a communication breakdown, the maintainer isn't solely responsible for that though. Communication is a two-way street.
Do you have a reference to back up the "Everything's fine" claim? My recollection is more like "the patches can't be merged due to these issues", which doesn't imply "everything's fine".
Posted Feb 1, 2025 13:28 UTC (Sat)
by ianmcc (subscriber, #88379)
[Link] (3 responses)
"It doesn't work like C. Rust builds the PCI bindings always once CONFIG_PCI is turned on. It doesn't matter if no rust driver is being built that consumes those bindings. It won't work like staging does where you can just turn off one driver."
The implication of this, as far as I can tell, is that if you change the API for, say, DMA, get it working in a simple test driver (with all other drivers that use the API disabled, because they won't build anymore), then that would normally be a point where you could start pushing the change to other people (staging?) to work on adapting the other drivers.
But if that API has rust bindings, then it will break as soon as CONFIG_RUST is turned on, because that will attempt to build the rust bindings, even if no actual rust drivers are configured in. And presumably CONFIG_RUST will, at some point, become non-optional if some core code is written in rust.
But that seems to be a configuration problem, and the fix is to get finer-grained control that only enables the rust bindings if there are rust drivers that need it, or the rust bindings are explicitly configured separately from CONFIG_RUST ?
Posted Feb 4, 2025 4:45 UTC (Tue)
by mbp (subscriber, #2737)
[Link] (2 responses)
Posted Feb 15, 2025 23:30 UTC (Sat)
by lacos (guest, #70616)
[Link] (1 responses)
Not good enough *if* calling the kernel "releasable" requires "CONFIG_RUST=y" to build.
- The maintainer starts work on a branch at whose fork-off point the kernel is "releasable".
I perceive this process as one manifestation of Hyrum's Law. I can see why the maintainer wouldn't want it.
Posted Feb 17, 2025 14:55 UTC (Mon)
by taladar (subscriber, #68407)
[Link]
You can either remove all the features that might potentially be affected by any code touched by any maintainer who does not know how to fix every single consequence of that code change exhaustively. You essentially turn the Kernel into a Hello World because that is likely most features.
Or you can restrict any maintainer from touching any code where they can't exhaustively fix everything that might potentially be affected by their code change. In that case the Kernel will likely never be changed again.
The problem you describe is not a Rust problem, it is a problem with an inability to work as a team.
Posted Jan 30, 2025 22:10 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (3 responses)
If, however, the rust chaps won't do that solely because it means maintaining code that's not in rust, then suddenly that seems to me to turn the tables 180 degrees.
Posted Jan 30, 2025 22:25 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link]
There are small parts of the glue code that are written in C and the Rust maintainers are already handling it just fine.
Posted Jan 30, 2025 23:39 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
Posted Jan 31, 2025 11:52 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Posted Jan 31, 2025 6:24 UTC (Fri)
by mcon147 (subscriber, #56569)
[Link] (2 responses)
Posted Feb 17, 2025 12:30 UTC (Mon)
by sammythesnake (guest, #17693)
[Link] (1 responses)
There seem to be some people who think the availability of a driver they don't like is some kind of horrible situation, but I'm not frankly very sympathetic to that position. Just set CONFIG_RUST=no and get on with your life (possibly writing a driver in C if you have sufficient motivation/ability)
Posted Feb 17, 2025 15:33 UTC (Mon)
by taladar (subscriber, #68407)
[Link]
Posted Jan 31, 2025 8:04 UTC (Fri)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Jan 31, 2025 14:36 UTC (Fri)
by notriddle (subscriber, #130608)
[Link] (1 responses)
I think it would be easier to make Rust for Linux a permanent downstream fork.
Posted Feb 7, 2025 12:47 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Jan 31, 2025 9:19 UTC (Fri)
by rsidd (subscriber, #2582)
[Link]
Posted Jan 31, 2025 9:38 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (24 responses)
It feels to me like the kind of legacy projects where even the people working on them don't really know how anything works any more and are desperately trying to avoid making any changes at all because there is no real way for them to predict the consequences of any change, mainly because most of the code was written by people long gone or dead and no assumptions or requirements were ever documented (or only a tiny subset).
Posted Jan 31, 2025 9:57 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (22 responses)
Yes the Rust maintainers claim they will do the work. But in the end we all know if you want to change an API you must fix all the places where the API is called. And if this gets merged it would include Rust.
So this maintainer should put everything on pause for a few months, to learn Rust well enough to write kernel code with it. Except that they can't just pause releases for a few months… so that leaves working all day and learning Rust by night?
You must be a Chinese factory owner to believe that this amount of work is ok.
Posted Jan 31, 2025 10:44 UTC (Fri)
by npws (subscriber, #168248)
[Link] (3 responses)
So you've stated that in response to every single thread in this comment section. Care to also point out the specific extra work he was "given"? From the emails, its quite clear that a) his opposition is generic, b) the Rust code is simply another consumer of the API and c) he's not expected to fix or do anything.
Posted Jan 31, 2025 17:43 UTC (Fri)
by wtarreau (subscriber, #51152)
[Link] (2 responses)
What I'm reading in all this thread is a huge confusion between "maintaining" and "developing". It's basically said "the work's already done blablabla". No. That's the development part. The maintenance part *starts* once the code gets merged and *ends* for developers. Maintaining means:
It's simply not a matter of sending a write-only code piece to someone and considering the job done over the week-end, it's a permanent, hard work. And the worst of this is that the maintainer's job is one of those that are the hardest to scale, because it's not just based on time and skills, it's based on experience. You can decide to have as many co-maintainers as you want, if you have 30 years of experience, it will take 30 years for a new one to be able to replace you with the same level of expertise, judgement and autonomy.
*That* is the problem.
I know Christoph can easily have harsh words, and I don't know the level of complexity of the proposed changes, but I know that as a maintainer of another software, it often happens to me to have to say "no" to some changes because I figure they will get us into hell, without the person in front of me being able to understand why, by lack of experience on that matter. So in this case, I have to sit down with the person and work for a few days to try to redesign their change with them in order to reach a point where nobody is able to envision a future major problem anymore (that doesn't mean there will be none, just that the maximum chances will have been put on our side). And it even happens with other highly skilled developers and maintainers for whom I have a lot of respect, just like some of them sometimes reject my changes for the same reasons. Keep in mind that every time an issue pops up, the first ones that are questioned are those who know the bits and bytes at the lowest levels and know how to read a backtrace, an hex dump or a network trace, and the vast majority of the time in the end it's not for them, it only allows to know whom to route it to.
The issue we're often reading here is "these bastards are rejecting our stuff, let's replace them". But it *exactly* illustrates the lack of maturity and experience needed to gauge the impacts of certain changes for existing maintainers. And there are areas that are trickier than others, just like there are maintainers who have more elasticity than other ones to adopt new technologies, and that's fine. But as a general rule-of-thumb, if you have not been forced to maintain an API you've designed for 10+ years regretting some early mistakes every single day you touch it, you just have no idea what a maintainers' difficulties are and you cannot qualify to judge their job nor their judgement, essentially based on intuition and recognized patterns.
It's certain that the form could be better. Christoph is known for not taking gloves. Others might just simply feel overwhelmed and decide to silently resign because they don't see themselves with a extra level of complexity. Others might just think "let's see, and I might give up later if/when it becomes too hard". Others might feel more at ease with estimating how to address shortcomings or might even try to themselves take part of the change. Nobody's equal and it takes of everyone to get a collective expertise as there is on Linux. Let's just not trivially dismiss the difficulties some may face in front of a task they did not decide to receive.
Posted Feb 1, 2025 0:07 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
That is not what Christoph did. He said[1] that he would not accept any Rust in "core systems" of the kernel, that he would not work with them on iterating the proposed solution, and that he would not allow anyone else to do that work in his stead. He also said[2] that he is opposed to further Rust in the kernel entirely.
> The issue we're often reading here is "these bastards are rejecting our stuff, let's replace them". But it *exactly* illustrates the lack of maturity and experience needed to gauge the impacts of certain changes for existing maintainers.
That is not what the RfL developers did. They started with the premise that Christoph was suggesting an alternative approach, and asked for specifics.[3] They escalated to Linus and Greg *only* in response to [1], at which point it was obvious that there was no alternative other than dropping the whole patch (which would seriously jeopardize the future of any Rust drivers that want to use DMA).
I can absolutely believe that there was room for further discussion of the specific approach to Rust-DMA integration. Sure, the patch was on revision 8, but 8 is not a magic number, and it's entirely plausible that they could've done further revisions if Christoph had asked for them. Christoph did not ask for revisions, because he does not want Rust-DMA integration to happen. He also strongly implied that he wants the RfL project as a whole to fail (or at least, to stop merging patches that add Rust to Linux, which is the whole premise of RfL). These are not inferences on my part. He said all of these things just in that one thread alone.
Seeing as Linus has already decided that RfL will be allowed to move forward for the time being, escalating to him and Greg was the right call. Christoph is directly challenging that decision, and it is not the place of the RfL developers (or anyone else) to determine whether or not Linus is going to change his mind based on Christoph's argument. Linus is the only person who can resolve this dispute, so he needs to be involved.
[1]: https://lwn.net/ml/all/20250128092334.GA28548@lst.de/
Posted Feb 16, 2025 0:03 UTC (Sun)
by lacos (guest, #70616)
[Link]
One of the best comments I've ever read on the internet (not just on LWN).
If you are a maintainer, then one way or another, you *will* be held responsible for any symptom that emanates even a *whiff* of your subsystem. You'll indeed be asked to triage it, and oftentimes, confidently saying that the bug is in some other (particular) subsystem or layer, requires reproducing and *completely* tracking down the bug. Sometimes you know *where* it is only when you learn *what* it is.
> Others might just simply feel overwhelmed and decide to silently resign
Right; that's what I've done once in the past, when I found myself in a somewhat similar situation as a co-maintainer in another project (I disagreed with both the feature and how exactly it was being developed). This is ultimately a fight for power (= who dictates what direction the project follows). Not everybody has the oomph that Christoph does, to take on the fight (I'm saying this *without* praising his particular style) -- I did quit (not silently, but civilly for sure).
I think Christoph has every right to resist a direction that he perceives as disruptive to his ability to maintain a project to which he has dedicated decades of his life. If he doesn't budge -- some differences may be irreconcilable --, the proponents of Rust can fork Linux, or can try to eject or marginalize Christoph.
We should be aware that "forking" is older and broader than "forking a software project". Here's an example:
https://en.wikipedia.org/wiki/Vienna_Secession
(And the funniest part of it: "the [seceded] group *itself* split, when some of the most prominent members [...] resigned in a dispute over priorities" (emphasis and light editing mine).)
Posted Jan 31, 2025 11:05 UTC (Fri)
by josh (subscriber, #17465)
[Link] (4 responses)
While this is the general rule in the kernel, the Rust-for-Linux work has specifically been excepted for this when Rust-for-Linux was approved, and neither Linus nor Greg have changed this. C maintainers are free to merge C changes without taking the Rust bindings into consideration, and the Rust maintainers will subsequently fix them.
Any individual maintainer who actively *wants* to support Rust could require that contributions to their subsystem keep the Rust bindings working, but that is not a requirement placed on any maintainer.
Posted Jan 31, 2025 17:33 UTC (Fri)
by laurent.pinchart (subscriber, #71290)
[Link] (3 responses)
I can't see how that rule could be preserved forever as more Rust code gets merged in the kernel. I also understand how some developers and maintainers can dread the time when breaking Rust bindings would block a patch series. Has there been any discussion on when that rule would change, and how to handle the fallout ? Without clear guidelines in that area, and a process to make the transition as smooth as possible, the fear this generates will keep impacting constructive collaboration very negatively.
Posted Jan 31, 2025 23:17 UTC (Fri)
by josh (subscriber, #17465)
[Link] (2 responses)
Posted Feb 2, 2025 22:48 UTC (Sun)
by laurent.pinchart (subscriber, #71290)
[Link] (1 responses)
That's what I would expect too, and is probably what most people expect as well.
The question has, as far as I can tell, not been officially addressed, and I think it is causing fears that hinder progress. I can imagine that, for a kernel developer or maintainer who wouldn't want to deal with Rust in the near or longer term (regardless of the reasons, that's not the point here), the prospect of a sudden and unilateral rule change would generate a hostile behaviour towards Rust in the kernel today. If one feels they are threatened by the project, they will have a higher incentive to make it fail.
Could the community try to address this question of long term fears ?
Posted Feb 3, 2025 2:03 UTC (Mon)
by dralley (subscriber, #143766)
[Link]
You're describing kernel developers sabotaging the kernel for self-motivated reasons because they don't like a decision that was made. What do you want the Rust developers to address, exactly? Nothing they do or say is going to release those "fears" or make someone that selfish see the light.
Posted Jan 31, 2025 17:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
Literally, yes. He should step away and learn Rust.
I'm absolutely serious.
If the development process is so focused on him that everything crashes and burns, then _this_ needs to be fixed.
Posted Jan 31, 2025 17:43 UTC (Fri)
by laurent.pinchart (subscriber, #71290)
[Link] (10 responses)
I've read many similar types of requests related to Rust in the Linux kernel. It's hard not to see a conflict with the initial promise of the RfL project that accepting Rust in the kernel won't affect maintainers who want to stay on the C side. Demanding that someone steps away from what they enjoy doing, to switch to a different programming language that they are not interested in (for good or bad reasons), is bound to alienate developers and maintainers.
Maybe the initial promise was not realistic (in the short, mid or long term), even if done in good faith, and will need to be reconsidered. There seem to be too many elephants in the room for things to go smooth.
Posted Jan 31, 2025 18:22 UTC (Fri)
by dralley (subscriber, #143766)
[Link]
People need to stop getting wrapped around the axle about imagined unreasonable requests.
The OP also shouldn't feed into the notion that such an expectation exists out of frustration with Cristoph.
But if the bus factor is so low that one person is the lynchpin for an entire subsystem, and that one person is rejecting changes that have minimal impact on them, and that person *also* refuses to allow anyone else to maintain those changes, then that is in fact a problem for the sustainability of the kernel.
If this was some new driver being stood up that needed to use DMA, and Christoph was objecting to that new subsystem on the basis that it could increase his maintenance workload whenever he made changes to an API, nobody would accept that reasoning. It would be completely absurd to block any new functionality from using DMA on that basis.
One of Linus' core stated motivations for the RfL project is increasing the kernel's accessibility to younger developers, something it is thus far succeeding at doing. I am certain it does occasionally frustrate maintainers to need to explain and document things and collaborate with new people, but that's kind of the whole point.
Posted Jan 31, 2025 18:22 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
Realistically, if you want to work on Linux, you will soon have to learn Rust. Practically, "soon" is still years away. Are you saying that Linux developers are not capable of learning something new, even given _years_ of lead time?
> Maybe the initial promise was not realistic (in the short, mid or long term), even if done in good faith, and will need to be reconsidered. There seem to be too many elephants in the room for things to go smooth.
I don't think the promise has been violated so far. In this case, nothing was required of Christoph Hellwig, the patches were CC-ed for him out of courtesy. Rust developers also promise to solve the breakages caused by changes on the C side of the kernel.
Posted Jan 31, 2025 18:37 UTC (Fri)
by mb (subscriber, #50428)
[Link] (7 responses)
It's not a burden to learn Rust and I could learn a lot about C while learning and using Rust.
I develop C applications in my day job almost exclusively.
Employers should give their C developers some free time to learn Rust.
And of course some kernel maintainers need to stop thinking that they are the navel of the world and the world stops spinning if they interrupt their important work to learn Rust.
Posted Jan 31, 2025 19:01 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
Hahahahahahahahahah... *snort*
I've been doing this a _long_ time now, and I have yet to see a single [prospective] employer let SW folks "train" on the company's dime (unless it's relatory-imposted stuff that has nothing to do with SW development)
> And of course some kernel maintainers need to stop thinking that they are the navel of the world and the world stops spinning if they interrupt their important work to learn Rust.
This goes both ways.
Posted Jan 31, 2025 19:22 UTC (Fri)
by mb (subscriber, #50428)
[Link]
Not sure why you are laughing, but that was exactly my point.
Posted Feb 1, 2025 1:20 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
I've ever had cases where a team of say four or five people are all watching the same training videos, for days at a time, breaking periodically to discuss among themselves what they've seen and write some toy example code. We tried to learn React that way years ago and I'd say about 10% of what I was taught is kinda sorta still there, so, it wasn't very effective but it was worth a try.
It's true that none of the start ups I've worked for had this, and that some of the larger industry companies weren't _good_ at it, although they did all claim to be supportive, but I think you got dealt a bad hand if you've been doing this "a long time" without seeing it once.
Posted Feb 1, 2025 2:12 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
I don't find the derisiveness suitable here. Several of the organizations I have worked for, did offer training for various things and yes, this included learning languages including Go and Rust. I don't think that is particularly uncommon. If Rust usage in Linux kernel increases, I wouldn't be surprised at all to see organizations involved offer such training.
Posted Feb 1, 2025 13:15 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
Sorry, but it's been my overwhelming experience [1] that employers would much rather rather *hire* someone with the "perfect" combination of skills [2] than actually invest in up-skilling an existing technical-role employee. On the other hand, management (and marketing/sales) folks are continually invested in and provided with any manner of internal opportunities for advancement, whereas technical folks nearly always have to find a different employer in order to utilize new skills, much less advance.
For example, $dayjob-1 had a program to help pay for a masters degree, if you signed a contract to keep working for them for a few years afterwards, but in practice it was only used to get MBAs because there were no technical career advancement opportunities in the entire _country_.
[1] from working at various organizations that were very small (< 10 total headcount) all the way to large multinationals (>60K), and interviewing with countless others. I have asked these questions in _every_ interview.
Posted Feb 1, 2025 13:37 UTC (Sat)
by mb (subscriber, #50428)
[Link]
I didn't say "Employers should give their C developers some free time to learn Rust." knowing they already do so. Right? That wouldn't make any sense.
But there *are* companies who do that. I work for one.
Posted Feb 2, 2025 0:21 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Your anecdotal experiences don't match mine but I am not going to claim either of our experiences are representations and if they are, your derision should be directed towards the organizations that refused to invest in their own employees and it wasn't clear to me that was the case.
Posted Feb 16, 2025 0:12 UTC (Sun)
by lacos (guest, #70616)
[Link]
I think the only time you can justifiably wish for a maintainer to step away if they are non-responsive (which isn't the case here). When they clearly and timely object, then "should step away" is an unjustified expectation; they *are* doing what they promised to do as a reviewer: namely, to comment on contributions. If you don't like their point, you can fork the code, or try to route around them (eject them from power, perhaps by escalating to someone higher up).
Posted Jan 31, 2025 14:56 UTC (Fri)
by corbet (editor, #1)
[Link]
Posted Jan 31, 2025 9:51 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (7 responses)
You can't force people. If you reach the point where you tell them "my way or the highway" they might chose the highway. And the whole goal of Rust in the kernel is to have more maintainers, not fewer.
I think the DMA maintainers would be satisfied if Rust had its own independent DMA code that does no calls to the C DMA code but implements everything from scratch. In that way a change of the C API would not require them to go and fix any rust code.
I presume this road hasn't been considered because it's complicated. But it would avoid offloading more work onto people who don't want to do this extra work, and keep it on the shoulders of people who claim they do want to do the work. So to me that would seem the fairest solution here.
Posted Jan 31, 2025 10:51 UTC (Fri)
by josh (subscriber, #17465)
[Link]
There isn't a genuine technical objection here, and this isn't something that a technical solution will fix. Christoph is attempting to block Rust in the kernel, calling it a "cancer" and saying "I will do everything I can do to stop this.". The correct response to such an escalation is to get him overruled and told that his "nack" will be ignored; nothing short of that is likely to work.
Posted Jan 31, 2025 11:37 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (4 responses)
I was thinking that. Do a "swap management" type stunt that Linus pulled ages ago.
I strongly suspect the result would be this huge blob of C legacy code would be replaced by a much smaller Rust blob, and Christoph would cease to be maintainer because the code would become an ex-Parrot.
Cheers,
Posted Jan 31, 2025 11:50 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (3 responses)
Posted Jan 31, 2025 14:47 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Cheers,
Posted Jan 31, 2025 15:03 UTC (Fri)
by dralley (subscriber, #143766)
[Link] (1 responses)
With respect to Rust in core kernel infrastructure, I don't think the architecture support concerns can be handwaved away like that. rustc_codegen_gcc is getting closer and closer to maturity every month, so this won't be a problem forever, but for the time being it still is.
Posted Feb 1, 2025 13:45 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
It would be very disappointing if that's what it takes, that somehow "Everything" is the lowest acceptable bar for "Anything" but I'd guess in the short term the only consequence is that the Rust priorities for 2025H1 get shorter by one item, no need to get Rust-for-Linux on stable Rust closer if in fact Rust-for-Linux is blocked until we can just rewrite everything in Rust anyway.
Posted Jan 31, 2025 14:43 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Do we want one maintainer jealously guarding his fiefdom, or four or five working as a team?
People who can't work as a team are a liability and single-handedly do a damn good job of discouraging newcomers.
Cheers,
Posted Jan 31, 2025 10:55 UTC (Fri)
by adobriyan (subscriber, #30858)
[Link] (42 responses)
RESF declared that all they want is to "write drivers", so it is not a replacement.
Posted Jan 31, 2025 11:03 UTC (Fri)
by josh (subscriber, #17465)
[Link] (3 responses)
Please don't conflate that harmful meme with any Rust project or Rust-for-Linux folks. Both groups specifically hate that meme and wish it would go away. Anyone inclined to push RESF memes should know that they're not helping Rust by doing so.
Posted Jan 31, 2025 11:20 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (2 responses)
Posted Jan 31, 2025 12:07 UTC (Fri)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Feb 2, 2025 19:48 UTC (Sun)
by adobriyan (subscriber, #30858)
[Link]
Posted Jan 31, 2025 12:54 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
What about all the programming languages ALREADY IN the code base?
The C macro processor is (technically) a different language. It's just nobody notices because it's been part of "the system" for so long, if not forever.
bash/make/whatever are also in the codebase, and they're not C. Okay, they're not part of the compiled kernel, but I believe BPF most definitely is?
Arguing "I don't want to learn a second language", when it's almost impossible to contribute without knowing three, four, five or more, is disingenuous in the least.
And lastly, as a (not that good) linguist myself, I would STRONGLY argue that knowing several languages typically makes you a better linguist IN ALL LANGUAGES. Computer-wise, I speak FORTRAN, C, and DataBASIC (I'd rather forget VBA :-). Okay they're all similar, it's easy to be reasonably fluent in all three. Throw Forth and Perl into the mix and skills bleed across. If only I could get to grips with Scheme, I'm sure it would markedly increase my skills in the other languages!
I get the complaint "learning a new language is something I don't have time for right now", or even "I'm getting too old" - Christoph has been around for ages. But saying "new languages are bad" as a blanket rule is just so awful it would be laughable if it wasn't tragic.
I think the Rust crowd need to take the same approach to DMA as appears to be happening with DRM. The C DRM maintainer didn't want to touch it (although that seems to have been a massive personality clash, not a "I hate Rust" situation), so we've ended up with two implementations, one in Rust and one in C. And if a Rust DMA manager arrives in let's say a year or so, which appears to be roughly the equal of the C version in maturity and bugginess, I think the writing will be on the wall for old dogs ...
Cheers,
Posted Feb 2, 2025 21:19 UTC (Sun)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
Yes, what about them? It is a mess. It is not as big mess as it could be.
Lets count them:
a) C
Only 3.5 execute on users machines and total amount of asm and BPF is quite small, so it mostly OK.
Now let's examine them more closely.
* C preprocessor is bananas.
You can't even write
#if sizeof(int) != 4
It just shows how they made terrible decision in the past and never fix it (by integrating the PP part with C part).
Kernel PP part is quite bad, large parts of Very Important kernel code (preemption, locking, percpu accessors, rcu, __user stuff)
Now that _Generic is allowed to be used, and at least some desire for ad-hoc polymorphism
I wrote the equivalent of "template<typename N, typename D> kdiv(N n, D d) -> N" at some point.
So, there will be more (garbage) sub-language in the future which is apparently will never get better.
* inline asm/real asm
AT&T syntax is the worst part of it. It became more macro heavy over time because of speculation fixes and getting more annotations.
* BPF
Jit over primitive VM -- whatever. Can't they load and verify real assembly?
* bc(1)
This is raw inability to constexpr.
* YAML
This is probably papering over anemic macro/constexpr system of the main language.
* Kconfig/Kbuild/Makefile
The argument here is basically, if you trust you main language to write OS kernel of all things
Makefiles are very different anyhow: mix of declarative and imperative programming.
> Arguing "I don't want to learn a second language", when it's almost impossible to contribute without knowing three, four, five or more, is disingenuous in the least.
Nobody is arguing this. I know a few too.
> And lastly, as a (not that good) linguist myself, I would STRONGLY argue that knowing several languages typically makes you a better linguist IN ALL LANGUAGES.
Ever heard of the Tower of Babel? :-)
> But saying "new languages are bad" as a blanket rule is just so awful it would be laughable if it wasn't tragic.
The statement is "new main programming language is bad unless it becomes the main programming language in foreseeable future".
> And if a Rust DMA manager arrives in let's say a year or so, which appears to be roughly the equal of the C version in maturity and bugginess, I think the writing will be on the wall for old dogs ...
There is nothing to be proud of as each distro has to decide which one to use, make effort to support both, splitting userbase, sorting bug reports, telling users to try the competing module, you know, all the good stuff of Open Source day-to-day life.
Posted Feb 3, 2025 12:55 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
> Ever heard of the Tower of Babel? :-)
It's on my grandfather's Coat of Arms :-)
Cheers,
Posted Jan 31, 2025 14:00 UTC (Fri)
by MortenSickel (subscriber, #3238)
[Link] (29 responses)
"Allowing second programming language into the codebase is (obvious) strategic blunder:"
"the only reason such thing is ever even initiated is to completely replace the original programming language."
Posted Feb 2, 2025 21:37 UTC (Sun)
by adobriyan (subscriber, #30858)
[Link] (28 responses)
Because they are source incompatible thus requiring constant efforts to sync in one direction.
It is a second shell for a crab.
But!
In real life, the original shell is discarded.
> "the only reason such thing is ever even initiated is to completely replace the original programming language."
If it is their foot-in-the-door strategy, then there is no problem.
Rust community essentially declared that C/C++ code is bad, broken, unfixable, untrustworthy, unsafe.
And they have the audacity to come to a big, old C project and want to make friends?
Posted Feb 2, 2025 21:42 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
I think that has been a consensus opinion for a long, long time by now?
> And they have the audacity to come to a big, old C project and want to make friends?
And why's that bad? A large C project is defined by its functionality, not by merely being written in C.
Posted Feb 3, 2025 11:44 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (13 responses)
This particular insight pre-dates Rust by a nontrivial number of years IMHO.
> I think that has been a consensus opinion for a long, long time by now?
Depends on who you ask. IIRC Bjarne Stroustrup seems to disagree rather vehemently, at least regarding the "unfixable" part.
Posted Feb 3, 2025 13:06 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (4 responses)
Given that C++ was supposed to be "a better C", and yet is still being dragged down by C compatibility, I think that's a rather untenable attitude (unless you're prepared to declare parts at least of C as "broken beyond repair" and ditch them).
Cheers,
Posted Feb 3, 2025 14:03 UTC (Mon)
by khim (subscriber, #9252)
[Link] (3 responses)
The problems that Linus complained about (namely: just compiling code in a C++ mode made it slower and templates left behind code that wasn't needed or used at all) were fixed, actually. Long ago. Linux wasn't complaining about the fact that C++ is unsafe, that would be stupid: C is even worse. It's the fact that they were fixed that made Rust-in-Linux project viable (because Rust inherited these fixed by nature of using LLVM). But today switching to C++ would make no sense because Rust picked up all the advantages of C++ that modern compilers offer and added safety to it. In the absence of Rust an attempt to bring C++20 or C++23 into kernel would have been a natural and positive change.
Posted Feb 3, 2025 16:46 UTC (Mon)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
The counterpoint is that Rust will never be able to reach 100% within the "second crab shell" model thus becoming permanent source of drama, dropped patches, hurt feelings and so on.
I have Realtek 8139 network card somewhere, lying unused for a long time of course.
Posted Feb 3, 2025 18:32 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Erm.... https://crates.io/crates/rtl8139-rs - it _already_ exists.
Posted Feb 4, 2025 9:01 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
It's not stupid because using two different, unsafe languages adds some "multi-language complexity" (what is being discussed here) for zero safety and not a lot in return.
Rust is being added to the kernel because it is NOT just an incremental improvement.
Posted Feb 3, 2025 19:33 UTC (Mon)
by sunshowers (guest, #170655)
[Link] (7 responses)
Posted Feb 4, 2025 9:51 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (6 responses)
And that figure has been pretty constant for many years.
Seriously. I doubt that figure has changed much. Modern languages make it easier to be more productive, but that's because they are more expressive - fewer lines to do more work. I don't know how many lines of solid production code I write a day, but when I get bitten by unexpected behaviour, when I get bitten by the language doing strange things, when I get bitten by corner cases, ... truly, you ARE a damn good programmer if you can beat Stroustrup's "2000 lines a year". And have your programs actually work!
Cheers,
Posted Feb 4, 2025 11:29 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
[1] One service is designed to be "bullet proof" and has never gone down; the other has had maybe 3 or 4 instances of errors taking down the service (out-of-date GraphQL schemas or new variants for REST APIs), but they've since been plumbed to be handled properly and it hasn't happened since.
Posted Feb 4, 2025 11:42 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Gah, typo'd the year in Python for this. It's actually about 14.1k (still way above Stroustrop's estimates). Anyways, I was also on (cumulative) vacation for about a year in this period, so it's probably actually more accurate anyways.
Posted Feb 4, 2025 11:45 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Sometimes I wonder about posters here :-) but I would have thought most people here would be well above average. And give them a language they enjoy using helps immensely.
I'm working with naff languages, so I wouldn't rate my productivity at all ... why write a one-line ENGLISH query, when two pages of SQL will do :-)
And VBA - it's a decent language but by $deity it drives you up the wall. And the documentation tells you everything except what you need to know - so corner cases bite you in the butt left right and centre ... oh well it pays the bills ...
Cheers,
Posted Feb 8, 2025 19:44 UTC (Sat)
by sunshowers (guest, #170655)
[Link] (2 responses)
2000 lines is the sort of figure you would achieve if you couldn't leverage modern tooling to offload as much thinking as possible to the compiler and other automation.
I pay a huge amount of attention to tests too, and in fact one of the things I maintain is a free (libre), cross-platform test runner for Rust that attempts to use state-of-the-art concepts to be the highest quality test runner in existence.
Posted Feb 8, 2025 19:53 UTC (Sat)
by sunshowers (guest, #170655)
[Link] (1 responses)
To put it bluntly, if my code output was 2000 lines a year, and I didn't have a very good justification for it (like spending most of my time doing non-code related things), I would have been fired for underperformance.
Posted Feb 10, 2025 10:07 UTC (Mon)
by taladar (subscriber, #68407)
[Link]
Posted Feb 4, 2025 3:56 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (12 responses)
It's a funny but the language was originally conceived to effect an in-place migration of a large C/C++ codebase, Mozilla/Firefox, but I'm not sure how the internal politcs of that actually worked as I don't think Firefox is being successfully transitioned to Rust, the Linux kernel seems likely to get there first. Maybe overall Linux has an actually healthier more collaborative community, even if it seems contentious at times, other large communities may be more so.
> Rust community essentially declared that C/C++ code is bad, broken, unfixable, untrustworthy, unsafe.
This is a technical judgement not a personal one, but of course people aren't perfect beings of thought and logic, they have egos too so some take this as a personal criticism or insult. It's true though that the tools to make Rust more reliable and debugged have been demonstrated to be great and getting better, all the people, hardnosed realists, sharing their positive experiences is evidence of that.
> And they have the audacity to come to a big, old C project and want to make friends?
It's hard to not get attached to what you know and find comfort and safety in, which can make it seem threatening when someone new shows up declaring they have a better way (does that mean your old way was "bad"?), but tools and technology do change and improve, tech changes can be evaluated on their merit and outcomes, and projects will stagnate if they put up a wall to defend their feelings from the work of learning new ideas presented in good faith, this isnt some existential struggle for dominance, so why wouldn't you want to be friends? Why present this as "audacious" and in a presumed negative tone? Why not make friends and either learn some exciting new techniques to make a great project even better, or pass the torch to the next generation who are excited for the opportunity to shine?
Posted Feb 4, 2025 4:17 UTC (Tue)
by dralley (subscriber, #143766)
[Link] (11 responses)
I don't think Linux is going to be beating that any time soon.
Posted Feb 4, 2025 9:57 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
If ten lines of Rust replace twenty lines of C, then you need to inflate the Rust figures with "dark code" to get an accurate picture. If it's the other way, you need to reduce the Rust code to prevent bloat skewing the picture.
Given that people seem to be much more productive in Rust, I would assume that you need fewer lines of Rust code, and hence need the "dark code" inflation.
Cheers,
Posted Feb 4, 2025 11:40 UTC (Tue)
by Trainninny (guest, #175745)
[Link]
How many LOC of Rust is there in Firefox if you subtract third_party/ ?
Posted Feb 4, 2025 14:07 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (8 responses)
Posted Feb 5, 2025 2:01 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (7 responses)
But, that metric is potentially misleading because huge sections of that pie are HTML and Javascript. Maybe as much as half the total code. The web browser is, after all, already designed to render HTML and execute Javascript, so it'd be dumb not to use that where applicable.
Clearly you are not going to rewrite some UI Javascript in Rust in more or less any scenario. So as a fraction of the "Systems Programming Language" parts of Firefox, Rust is much larger, the biggest portion is C++, then there's a lot of C, shortly behind that is Rust, then there's a very small amount of assembler, presumably mostly in the cryptography and video codecs.
Posted Feb 5, 2025 4:57 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (1 responses)
./
third_party/
third_party/rust/
How many of these LOC are Firefox Rust code, and how many are vendored Rust code?
C++ (LOC):
./
Posted Feb 7, 2025 12:29 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
If anything having huge amounts of code directly in your code-base without any split into libraries is a code smell, the next best thing is code only you can use but that is at least properly split into theoretically reusable libraries with a well defined interface and the best option is using reusable code that can be used for other projects too.
Posted Feb 5, 2025 6:26 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
I would not call 100k lines of assembler "small" by any measure, but of course it's dwarfed by their multi-million lines of Rust and C(++).
Posted Feb 5, 2025 6:58 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (3 responses)
If it is true, then Rust would have less than 10% LOC of the C++ code.
Posted Feb 5, 2025 11:32 UTC (Wed)
by excors (subscriber, #95769)
[Link] (2 responses)
So "third_party" doesn't mean they're developed by third parties - it seems more like a sign that a library's primary home is outside the gecko-dev repository, which includes Mozilla-developed ones that are designed to be usable by non-Mozilla projects too. (Many of them are implementing web standards, so there's a good chance others will find them useful). Mozilla periodically imports them into gecko-dev and often applies some local patches, presumably to fit in with Mozilla's stability requirements and release cycle; they'll submit fixes upstream too, but I guess they don't want to wait for upstream to apply the fix and then risk regressions by pulling the latest upstream release, hence the vendoring and patching.
Posted Feb 5, 2025 17:52 UTC (Wed)
by Trainninny (guest, #175745)
[Link] (1 responses)
I believe the example libraries of Mozilla Rust code that you mention that are focused on the browser, could be fair to include those as Firefox Rust code. So a ballpark figure of how many Rust LOC that Firefox has, could maybe be 600K LOC of Rust in third_party/, making the ballpark figure of Rust in Firefox 1000K LOC, which is about 20% of C++ LOC in Firefox. A substantial amount, if my ballpark figure is not way off.
Posted Feb 7, 2025 12:31 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Feb 2, 2025 18:46 UTC (Sun)
by edomaur (subscriber, #14520)
[Link] (2 responses)
Posted Feb 2, 2025 19:50 UTC (Sun)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
Posted Feb 3, 2025 18:59 UTC (Mon)
by edomaur (subscriber, #14520)
[Link]
Hovewer, even if you restrict usage to C++ only, you'll get a huge amount of divergence. Each language will get many dialects, and various hardware will have different architectures and various asm approaches. It's just not possible to just get "one language to govern them all" when the basis of the system is not homogenous itself.
Posted Feb 3, 2025 16:37 UTC (Mon)
by StillSubjectToChange (guest, #128662)
[Link] (1 responses)
This is quite a damning and contemptuous statement towards C. What does it say about a language if it will die out in the presence of an alternative? Or rather, why do the Linux kernel maintainers need to protect C by banning every other language?
Java didn't replace COBOL. Bash, Perl, Tcl, JCL, etc have not been replaced by Python or JS. C++ hasn't replaced C, etc. Considering the disgusting amount of C code that struggles to find maintainers, with fewer still wanting to conduct a full on rewrite, it's safe to say that C won't be decimated by Rust anytime soon. Like any other programming language, C codebases are replaced once they become obsolete for one reason or another. For instance, drivers for hardware that was released 10+ years ago, or applications for businesses which have gone bankrupt/defunct/acquired/closed down/etc. Although governments and other exceptionally large institutions will continue using "legacy" languages over truly enormous time frames.
Posted Feb 3, 2025 21:22 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Why is it “safe to say”? To “decimate” is to kill one our of ten… 10 (ten) is where “deci” comes… looks pretty sensible that Rust would be able to do that in a few years to C projects. Full replacement? Now that is trickier… I don't expect that Rust would be able to achieve that before we'll get next language, around 20-30 years down the road, that would do to Rust what Rust does to C right now.
Posted Jan 31, 2025 13:07 UTC (Fri)
by ebiederm (guest, #35028)
[Link] (10 responses)
The code as described wasn't a Rust version of the DMA API but was instead some driver specific hack being generalized for more drivers.
None of this sounds like the Rust folks put much thought or energy into what they were doing.
Copying Christoph and with a driver specific hack does not give the impression they were considering anything from a maintainers perspective or from a long term maintenance perspective.
If this was really supposed to be something that the Rust developers plan to maintain themselves why was Christoph copied?
If this was really supposed to be a long term maintainable wrapper of the DMA API why was it such a half assed effort?
To me it looks like the Rust developers in question were trying to dump some half-assed thing that will be a maintenance problem in Christoph's lap. Which seems like a perfectly valid reason to reject the code.
That none of this is obvious from the Rust side siggests there is a lot of learning about Linux the Rust developers need to do. At a minimum don't CC people when you don't plan to involve them.
Posted Jan 31, 2025 15:45 UTC (Fri)
by dmv (subscriber, #168800)
[Link] (8 responses)
Posted Jan 31, 2025 17:11 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Yeah, you can justify it as "this patchset touches the raid code", but when it's 30-40 emails per patch set, of which just ONE might be of any relevance, and the patch set goes through maybe 10 revisions ...
No I'm not complaining. Maybe the emails were informative to other people on the list. The emails WERE of passing curiosity interest to me. But to complain that you're being spammed with emails that *might* be of interest, when you have a habit of doing exactly the same to other people, stinks of double standards.
Plus, when I'm using my email client of choice - and my corporate gmail is not it! - it's pretty easy to separate out all the cc's into a separate folder and only look at the emails sent directly to you, if that's what you want.
Cheers,
Posted Jan 31, 2025 17:22 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
You can't win.
Posted Feb 1, 2025 12:24 UTC (Sat)
by ma4ris8 (subscriber, #170509)
[Link] (5 responses)
One Finnish inventor, holding 162 patents, was interviewed yesterday in TV.
Three cases come to mind; tooling, architecture and mental side:
1. Changing C API: does it have to break Rust compilation? Decouple C and Rust API changes.
2. Robust way of grepping both C and Rust codebases. Find and see all function callers easily.
3. Mental side: learn to listen. I feel lack of the skill, and need to learn it better.
Posted Feb 1, 2025 13:29 UTC (Sat)
by mb (subscriber, #50428)
[Link] (4 responses)
The Rust side of the binding needs to be sound beyond what the C type system provides.
Changing a struct might be Ok or might not be Ok. But one can only be sure after checking of the Rust code. Grepping the source code doesn't really help to do that. Knowledge about Rust is required to do that.
This is what the R4L people will do.
Posted Feb 1, 2025 22:22 UTC (Sat)
by dralley (subscriber, #143766)
[Link]
Which also has to be done for every C caller of that API. Some of those callers may even require subsystem-specific knowledge to change, at which point you're working in collaboration with another developer no differently than you might need to work with an R4L developer.
Posted Feb 2, 2025 10:01 UTC (Sun)
by ma4ris8 (subscriber, #170509)
[Link] (2 responses)
Sometimes in music there are irregularities,
Still, learning a song can be done. No need to say to the composer:
So in this case, either lower level library is written in C or in Rust.
If it is possible to test and develop the lower level library independently
Lower level library author is aware of constraints, perhaps not all.
Some cases need tight co-change with Rust and C changes at the same merge request.
My opinion is that Rust safety is becoming a baseline
I don't know how to unblock the progress. Sometimes there need to wait a bit
Posted Feb 2, 2025 16:11 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Apologies for going off topic, but this embodies EVERYTHING that is WRONG with Western Music.
How do you check whether your didgeridoo music is okay on a piano? How do you even PLAY your Indian quarter-tone music on a piano? How do you tell whether you've got the balance right between the piercing trumpet, the sonorous flugel, and the rounded cornet on a piano?
The piano is the musical equivalent of BASIC - a lowest common denominator that everyone is forced to damage their mind with before they are allowed to move on ...
The piano has totally and utterly poisoned the concept of Music here in the West ...
Cheers,
Posted Feb 8, 2025 3:27 UTC (Sat)
by ssokolow (guest, #94568)
[Link]
Posted Jan 31, 2025 16:45 UTC (Fri)
by ferringb (subscriber, #20752)
[Link]
Careful now, you might wind up describing how the kernel got things like the VFS and basically every other fricking subsystem abstraction. That might also be why the patch was "abstraction" rather than "rust version of DMA API" (which already exists- FFI'd in).
A bit directly, this is lwn, not twitter. Keep the signal/noise saner please.
Posted Feb 3, 2025 13:56 UTC (Mon)
by jgg (subscriber, #55211)
[Link]
Corbet, I would suggest this does not quite capture the conversation.. Now that v6.14-rc1 is out we can see the following 6 patches, previously accepted by Andrew, were fully dropped from the merge window only because they broke Linus's Rust build:
Uros Bizjak (6):
Andrew quickly resent his PR without those patches. It was not "delayed" that was being noted, but the above full drop of patches. Rust issues certainly held up Uros's project.
Posted Feb 3, 2025 18:18 UTC (Mon)
by asahilina (subscriber, #166071)
[Link]
For once I'm glad I don't have to be part of the latest drama. drm/asahi does not depend on the DMA framework, since it does not support IOMMUs or use "typical" DMA mapping stuff. The page tables are managed by the GPU driver and map to physical memory directly, so the driver only interacts with the GEM subsystem (which returns sg_tables with lists of physical memory pages) and the raw page allocator to build page tables, and does not use the "DMA MAPPING HELPERS" (which is the subsystem this article is about).
So interesting drivers that do DMA can be written without this... (some) integrated GPU drivers, and probably not much else.
Posted Feb 6, 2025 16:53 UTC (Thu)
by rbranco (subscriber, #129813)
[Link] (2 responses)
https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f7...
"Rust folks: Please don't waste your time and mental cycles on drama like this. It's not worth your time. Either Linus likes it, or he doesn't. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages."
This language is 13 years old. It's about time it gets a formal spec and picks steam.
Posted Feb 6, 2025 20:56 UTC (Thu)
by dpc (guest, #74012)
[Link] (1 responses)
The idea of wasting time re-deriving description of something into yet another artifact using less precise formalism is just silly. It is from the era of propriety programming languages implementations, where the language was trivial and competing implementations wanted to agree on the formalism. Nowadays you will not touch a PL which doesn't have an open source implementation, and the languages are complex and constantly evolving. You want to standardize, you can just pick a version of the code from time to time, and make that as the standard.
Posted Feb 7, 2025 11:51 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Posted Feb 7, 2025 21:37 UTC (Fri)
by foom (subscriber, #14868)
[Link]
It's unfortunate, because I thought his earlier email was a great suggestion—recommending that Rust-for-Linux folks should not waste any more time debating with hostile maintainers, and just wait for Linus to decide whether to pull the patch series or not. Following his own recommendation there seems like it could've resulted in leaving space for the right thing to happen, without creating additional drama...
Rambling
- But also blocking other people offering to maintain the not C outside of his domain ?
Rambling
Rambling
Doesn't make sense to me.
Rambling
Rambling
Rambling
Rambling
Rambling
You can rustify the entire tree downstream and nobody can stop you, so what's your point?
Rambling
Rambling
Rambling
Wol
Rambling
Rambling
Extra work?
Extra work?
Extra work?
Extra work?
This really shouldn't hold up anything on his end at all.
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
- 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.
Rambling
> [...]
> BTW this technique of "breaking stuff for discovery" is very useful in general, ...
Rambling
Rambling
> 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
Rambling
Rambling
Wol
Rambling
Rambling
Rambling
Wol
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
> If some work is not done as a result of this, then it will force the stakeholders to allocate proper resources.
> I hope it's just me not being up to date, and everybody else knows there are good answers.
Rambling
This would, of course, have severe consequences:Rambling
He's not immortal, for one thing.
> How would you know?
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Wol
Rambling
Science progresses one funeral at a time.
https://en.m.wikipedia.org/wiki/Planck%27s_principle
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
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
Rambling
If a maintainer, like Christoph Hellwig, steps down, the whole kernel becomes a pile of ruins very quickly
Rambling
Rambling
Rambling
Rambling
Rambling
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."
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
Rambling
IDE rewrites - https://lwn.net/Articles/8123/
Rambling
Cancer?
And there are more than enough of them.
And this is not a new thing.
It's a structural problem in the maintainer network that has been there for decades and it spreads up into very top positions of the maintainer tree.
Cancer?
> And there are more than enough of them.
Cancer?
And there are more than enough of them.
Cancer?
Cancer?
Cancer?
Cancer?
The 6.13 kernel had 254 first-time contributors — an entirely typical number. The kernel community may have problems, especially when it comes to maintainers, but it is not "lacking new contributors".
New contributors
New contributors
New contributors
New contributors
New contributors
Wol
New contributors
New contributors
Wol
New contributors
New contributors
New contributors
New contributors
New contributors
New contributors
New contributors
Cancer?
Cancer?
* C is a well established language and it's easy to get stuff into distributions
* A lot of dependencies won't have bindings or equivalent for rust
* C is easier
Cancer?
Cancer?
Cancer?
Cancer?
Cancer?
Cancer?
Cancer?
Cancer?
Cancer?
Relative difficulty
Relative difficulty
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
The Nomicon is talking about something different; if you have an invariant that unsafe code depends upon, but that can be broken by the actions of safe code, that's not OK unless you can guarantee that you have audited all of the safe code that could break the invariant. A module boundary provides that guarantee - if the only things that can break the invariant are in the same module as the unsafe code, then you can guarantee that you have audited all of the safe code that can break the invariant.
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Wol
Learning Rust
unsafe in Rust is harder than writing code in C, but that's, to some extent, inevitable: hardware is “unsafe”, working with page tables is “unsafe” and so on. Sure, 90% of you code wouldn't trigger these, but some code have to do “unsafe” operations (as long as our hardware is not safe, anyway… but currently that's the case) – and if only 10% of your code can do that… of course it becomes harder: you have concentrated unsafety in a smaller (often much smaller) amount of code.unsafe code” is higher than “effort per line of C code”, but total amount of effort that you need to spend to achieve something is reduced.Learning Rust
>
>-
>
>Self-referential data structures are a well-known challenge in Rust. They require unsafe code.
>
>-
>
>Note: This may have been a MIRI bug or the rules have since been relaxed, because I can no longer reproduce as of nightly-2024-06-12. Here’s where the memory model and aliasing rules not being defined caused some pain: when MIRI fails, it’s unclear whether it’s my fault or not.
>
>-
>
>Note: This may have also been a MIRI bug. It is no longer reproducible.
>
>-
>
>Until the Rust memory model stabilizes further and the aliasing rules are well-defined, your best option is to integrate ASAN, TSAN, and MIRI (both stacked borrows and tree borrows) into your continuous integration for any project that contains unsafe code.
>
>If your project is safe Rust but depends on a crate which makes heavy use of unsafe code, you should probably still enable sanitizers. I didn’t discover all UB in wakerset until it was integrated into batch-channel.
>
>-
>
>Without MIRI, it would be hard to trust unsafe Rust.
>
>-
>
>References, even if never used, are more dangerous than pointers in C.
Learning Rust
Wol
Learning Rust
Learning Rust
Wol
Learning Rust
Learning Rust
Wol
Learning Rust
>
>Which makes Rust (in general) much easier/safer than C/C++, because most programmers don't (have to) go near that stuff - it's safely walled off in clearly marked danger zones.
>
>Rust doesn't have the "strict aliasing" rules from C and C++.
>
>But all Rust references are effectively "restrict" pointers, so getting unsafe Rust right is harder in practice.
>
>It would be nice never to have to worry about any of this, but it turns out that a lot of optimizations don't work without aliasing information.
>
>-
>
>Self-referential data structures are a well-known challenge in Rust. They require unsafe code.
>
>-
>
>Note: This may have been a MIRI bug or the rules have since been relaxed, because I can no longer reproduce as of nightly-2024-06-12. Here’s where the memory model and aliasing rules not being defined caused some pain: when MIRI fails, it’s unclear whether it’s my fault or not.
>
>-
>
>Note: This may have also been a MIRI bug. It is no longer reproducible.
>
>-
>
>Until the Rust memory model stabilizes further and the aliasing rules are well-defined, your best option is to integrate ASAN, TSAN, and MIRI (both stacked borrows and tree borrows) into your continuous integration for any project that contains unsafe code.
>
>If your project is safe Rust but depends on a crate which makes heavy use of unsafe code, you should probably still enable sanitizers. I didn’t discover all UB in wakerset until it was integrated into batch-channel.
>
>-
>
>Without MIRI, it would be hard to trust unsafe Rust.
>
>-
>
>References, even if never used, are more dangerous than pointers in C.
>
>-
>
>So first of all: does this [Rust unsafe] work now? The answer is yes. But is it correct? The answer is not.
>
>-
>
>It's 2022 and I will admit that I no longer feel confident writing unsafe Rust code. The rules were probably always complex but I know from reading a lot of unsafe Rust code over many years that most unsafe code just did not care about those rules and just disregarded them. There is a reason that addr_of_mut! did not get added to the language until 1.53. Even today the docs both say there are no guarantees on the alignment on native rust struct reprs.
>
>Over the last few years it seem to have happened that the Rust developers has made writing unsafe Rust harder in practice and the rules are so complex now that it's very hard to understand for a casual programmer and the documentation surrounding it can be easily misinterpreted. An earlier version of this article for instance assumed that some uses of addr_of_mut! were necessary that really were not. And that article got quite a few shares overlooking this before someone pointed that mistake out!
>
>These rules have made one of Rust's best features less and less approachable and also harder to understand. The requirement for the existence MaybeUninit instead of “just” having the old mem::uninitialized API is obvious but shows how complex the rules of the language are.
So these posts are increasingly beginning to look like trolling, and do not appear to be adding anything useful to the discussion. Perhaps it's time for both the posts and the responses to stop?
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Wol
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Learning Rust
Wol
Learning Rust
Learning Rust
Wol
Learning Rust
Learning Rust
Learning Rust
Wol
I thought this thread was about Learning Rust, not Learning English! Nevertheless, I'm just going to quote Wikipedia, Exception that proves the rule:
Learning Rust
Two original meanings of the phrase are usually cited. The first, preferred by Fowler, is that the presence of an exception applying to a specific case establishes ("proves") that a general rule exists. A more explicit phrasing might be "the exception that proves the existence of the rule." Most contemporary uses of the phrase emerge from this origin, although often in a way which is closer to the idea that all rules have their exceptions.
The article does then go on to describe a few other ways in which the phase may be interpreted, including the meanings which people are arguing are the only possibly-correct meaning in this thread.
> "the exception proves the rule"
Learning Rust
There's a deep cultural divide here; doing any C that's fully defined by the Standard is as hard as doing unsafe Rust, but with C, the compiler authors recognise that there are limits to how far they can go with "this is undefined/unspecified/implementation defined per the Standard, and we're choosing to exploit that for optimization", whereas Rust with its split between unsafe and safe Rust can break any unsafe code whose behaviour isn't fully defined.
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
Right, but there are things that are technically UB in C or C++ but where compilers do what was intended by the author because there's so much code out there that depends on a specific meaning for that UB, to the point where there exist compiler flags like -fno-strict-aliasing and -fwrapv whose sole purpose is to tell the compiler to define certain things that the Standard says are UB in a specific fashion.
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
Your counter example talks about something very different - once the compiler has decided that it's not going to define the meaning of a piece of code that contains UB, the risks are the same with Rust or with C.
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
>
>-
>
>Self-referential data structures are a well-known challenge in Rust. They require unsafe code.
>
>-
>
>Note: This may have been a MIRI bug or the rules have since been relaxed, because I can no longer reproduce as of nightly-2024-06-12. Here’s where the memory model and aliasing rules not being defined caused some pain: when MIRI fails, it’s unclear whether it’s my fault or not.
>
>-
>
>Note: This may have also been a MIRI bug. It is no longer reproducible.
>
>-
>
>Until the Rust memory model stabilizes further and the aliasing rules are well-defined, your best option is to integrate ASAN, TSAN, and MIRI (both stacked borrows and tree borrows) into your continuous integration for any project that contains unsafe code.
>
>If your project is safe Rust but depends on a crate which makes heavy use of unsafe code, you should probably still enable sanitizers. I didn’t discover all UB in wakerset until it was integrated into batch-channel.
>
>-
>
>Without MIRI, it would be hard to trust unsafe Rust.
>
>-
>
>References, even if never used, are more dangerous than pointers in C.
>
>-
>
>So first of all: does this [Rust unsafe] work now? The answer is yes. But is it correct? The answer is not.
>
>-
>
>It's 2022 and I will admit that I no longer feel confident writing unsafe Rust code. The rules were probably always complex but I know from reading a lot of unsafe Rust code over many years that most unsafe code just did not care about those rules and just disregarded them. There is a reason that addr_of_mut! did not get added to the language until 1.53. Even today the docs both say there are no guarantees on the alignment on native rust struct reprs.
>
>Over the last few years it seem to have happened that the Rust developers has made writing unsafe Rust harder in practice and the rules are so complex now that it's very hard to understand for a casual programmer and the documentation surrounding it can be easily misinterpreted. An earlier version of this article for instance assumed that some uses of addr_of_mut! were necessary that really were not. And that article got quite a few shares overlooking this before someone pointed that mistake out!
>
>These rules have made one of Rust's best features less and less approachable and also harder to understand. The requirement for the existence MaybeUninit instead of “just” having the old mem::uninitialized API is obvious but shows how complex the rules of the language are.
>
>Rust doesn't have the "strict aliasing" rules from C and C++.
>
>But all Rust references are effectively "restrict" pointers, so getting unsafe Rust right is harder in practice.
>
>It would be nice never to have to worry about any of this, but it turns out that a lot of optimizations don't work without aliasing information.
Your wall of text does not back your claim that my argument is wrong - indeed, it doesn't even address it at all.
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
Wol
Do not feed the troll. Please.
Second request
Second request
Unsafe Rust versus C and C++
>
>-
>
>[...]90% of Rust programmers are unlikely to step outside the safe zone in their entire career. [...]
>
>THAT is why unsafe code is hard. Because the maths behind it is hard. Knuth ranks his problems from 0 is "easy" to (iirc) 5 is "if you can solve it it's worth a PhD". As soon as you start programming "unsafe", you are dealing with code where the proofs are 4 or 5 on the scale - if it's even provable!
Your comments are trolls - lengthy pieces designed to prolong conversations and make people argue. They are off-topic for an article on kernel development. Whether or not they actually are, they certainly have the look of machine-generated text. I am done asking you to stop, you really need to put an end to this here.
Stop here.
Unsafe Rust versus C and C++
Wol
Unsafe Rust versus C and C++
>
>-
>
>Self-referential data structures are a well-known challenge in Rust. They require unsafe code.
>
>-
>
>Note: This may have been a MIRI bug or the rules have since been relaxed, because I can no longer reproduce as of nightly-2024-06-12. Here’s where the memory model and aliasing rules not being defined caused some pain: when MIRI fails, it’s unclear whether it’s my fault or not.
>
>-
>
>Note: This may have also been a MIRI bug. It is no longer reproducible.
>
>-
>
>Until the Rust memory model stabilizes further and the aliasing rules are well-defined, your best option is to integrate ASAN, TSAN, and MIRI (both stacked borrows and tree borrows) into your continuous integration for any project that contains unsafe code.
>
>If your project is safe Rust but depends on a crate which makes heavy use of unsafe code, you should probably still enable sanitizers. I didn’t discover all UB in wakerset until it was integrated into batch-channel.
>
>-
>
>Without MIRI, it would be hard to trust unsafe Rust.
>
>-
>
>References, even if never used, are more dangerous than pointers in C.
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
Unsafe Rust versus C and C++
"Must still uphold all safe Rust invariants. You just get access to new constructs with more lax rules," aside, when people well-versed in Rust say Learning Rust
unsafe Rust is harder than C, they're often referring to one specific footgun-for-C-programmers case which has since been made less serious with the introduction of the &raw operator in October 2024.
& operator will create a temporary & or &mut (non-raw) reference which must uphold the validity invariants, so it's instant UB to use it to construct *const or *mut (raw pointers) which alias in situations where legal-with-raw-pointers aliasing is allowed.
std::ptr::addr_of! and std::ptr::addr_of_mut! macros to take raw-pointer references to things without being required to uphold the aliasing invariants.
Cancer?
Cancer?
Cancer?
And please understand who introduced this ridiculous term of "cancer" in the first place.
Ok?
Calling somebody or something names is not going to do anything useful.
You may say that Rust is bad because it doesn't support as many CPU architectures as C does.
You may say that Rust is bad because it sometimes has a small runtime overhead in certain situations.
etc, etc...
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
If you grep through the kernel repository you'll find an occasional commit with that tag. Merging a patch that has been nacked in that way is an explicit override of the maintainer and is rarely done, though. Usually a lot of discussion has to happen first, and it takes somebody with a lot of authority to do the merge, if it comes to that.
Nacked-by
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Wol
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Wol
Time to step up, Linus/GregKH
Wol
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
> pure C driver, but the maintainer was rejecting her opinion on the basis of being a "Rust person talking about lifetime issues" despite this.
>
> In both cases the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint.
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
Time to step up, Linus/GregKH
- The maintainer changes C APIs.
- The maintainer fixes up all C-language call sites across the tree.
- The API changes break the Rust bindings.
- The maintainer doesn't care (or even notice) because they build with Rust disabled. Even CI may pass for them, that way. (They might also have some customization for git-grep in order to exclude Rust source files altogether -- i.e., they wouldn't see any API call sites they wouldn't want to fix up.)
- The result is however, *presumably*, an "unreleasable" kernel, because "CONFIG_RUST=y" no longer builds.
- The maintainer ultimately performed a series of actions that turned a releasable kernel into an unreleasable one.
- The Rust-proponent maintainers now have to come in and clean up "after" the original maintainer, in order to restore the tree to "releasable" state.
Time to step up, Linus/GregKH
Third way
Third way
Third way
The objection is to any glue code, regardless of the language it's written in. If it's there to enable bindings to another language, rather than for a C driver that cannot be written with the current abstractions, then it will get nacked, regardless of whether it's written in C, Rust, Python, F#, or INTERCAL, and regardless of what language it's meant to enable you to use. Hellwig has been quite clear that the intention is to force all drivers that do DMA to be written in C, as a way to ensure that the amount of non-C code in the kernel is kept small (and thus easy to remove).
Third way
Momentum
Momentum
Momentum
Copy it but keep it the same
Copy it but keep it the same
Copy it but keep it the same
Back in 2021 Hellwig wrote
Moving goalposts...
Not sure if this is just a state of the union post or if you actually want to submit it. If the later I strongly disagree with merging it, as you should refined it and prove it actually is useful first. Where useful would be a real-life driver like say nvme or a usb host controller driver that actually works and shows benefits over the existing one. Until it shows such usefulness it will just drag everyone else down.
(this was in response to a patch series from Miguel Ojeda). Four years later there are actual useful rust drivers (essential on some platforms), but that's not good enough.
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
- reading unqualified bug reports that possibly look like they might be related to what you're working on, and scratch one's head to try to guess if that could be related or not.
- helping reporters get more traces, debug info, run tests, patches etc to try to better figure the problem
- write fixes and test them or get them tested
- deal with backports (a nightmare in some API changes, especially when patches apply and build fine while you know the API differs)
- deal with security reports, in particular the mighty ones where you're supposed to be discrete and not request everyone's help since you're a maintainer and you know.
- and all that most often alone before others have a look, or even against those who initially say "it's probably something over there".
Deeper problems in the Linux kernel
[2]: https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
[3]: https://lwn.net/ml/all/CANiq72=R2N+QiCiHZQu-6YJ9aYpn_bik3...
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
And learning Rust made me a better C developer. I would be surprised if that would only be a personal phenomenon that would not apply to some of these kernel developers as well.
And I'm pretty sure that I got better at it after learning Rust.
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
> I've been doing this a _long_ time now, and I have yet to see a single [prospective] employer let SW folks "train" on the company's dime (unless it's relatory-imposted stuff that has nothing to do with SW development)
Deeper problems in the Linux kernel
[2] Cue the "ten years experience with a technology that's three years old" job requirements.
Deeper problems in the Linux kernel
I know that most employees don't do that or only do it at a very minimal level. That was my whole point.
Deeper problems in the Linux kernel
Deeper problems in the Linux kernel
You can agree with Christoph's position or not, but I have to say that any assertion that he is driven by a lack of understanding of the DMA layer is incorrect. That's not what is going on here.
Deeper problems in the Linux kernel
Duplicate the DMA in Rust
Duplicate the DMA in Rust
Duplicate the DMA in Rust
Wol
Duplicate the DMA in Rust
Duplicate the DMA in Rust
Wol
Duplicate the DMA in Rust
Duplicate the DMA in Rust
Duplicate the DMA in Rust
Wol
multi-language code base
the only reason such thing is ever even initiated is to completely replace the original programming language.
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
Wol
multi-language code base
aa) CPP (see below)
b) inline asm
c) real asm
d) BPF
e) lonely bc script for time conversions
f) Kconfig/Kbuild
g) Makefile
j) yaml for netlink and hardware configs
h) random junk (bash, rpm, deb, everything else)
#error
#endif
goes through CPP. At some point I realized that it is faster (and more reliable) to preprocessor some files and indent them
then to jump with tags over macrology sometimes unsure if you've jumped the the right place.
there will be more preprocessor in the future.
Thanks God, I never sent it (dispatch on 2 args, ouch).
Visually it is less and less an assembly.
Using whitespace-sensitive language should have never been allowed in the first place
(because everything else is whitespace insensitive except tabs in Makefile).
they why don't you trust it to use it to build itself.
multi-language code base
Wol
multi-language code base
Why would it be? If something in some way or another is better than C for kernel development, why not use it?
This may be your idea, but why project that on others? And, if in 20 years we have a better kernel written in rust, what is the problem?
multi-language code base
> > "Allowing second programming language into the codebase is (obvious) strategic blunder:"
> Why would it be? If something in some way or another is better than C for kernel development, why not use it?
Right now the amount of Rust code is relatively small but there will be more and more Rust in the future as they will cover more and more kernel subsystems (in theory, all of them).
> This may be your idea, but why project that on others? And, if in 20 years we have a better kernel written in rust, what is the problem?
multi-language code base
multi-language code base
multi-language code base
Wol
multi-language code base
multi-language code base
But they will never convert 8139cp.c and 8139too.c to Rust because why would anyone waste their time on such obsolete hardware.
multi-language code base
multi-language code base
multi-language code base
multi-language code base
Wol
multi-language code base
[2] Well, I've done 90%+ of it, but at least been part of the review of everything else.
multi-language code base
multi-language code base
Wol
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
Wol
multi-language code base
multi-language code base
multi-language code base
multi-language code base
, and cloc, I get the following results for Rust (LOC):
3603184
3263055
3263037
5488817
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
multi-language code base
> it's safe to say that C won't be decimated by Rust anytime soon
multi-language code base
Rust Developer words and actions do not align
Rust Developer words and actions do not align
Rust Developer words and actions do not align
Wol
Rust Developer words and actions do not align
Rust Developer words and actions do not align
He was asked, what was his secret? He told that he must have more problems,
compared to others. We have here emphasized problems, thus this is a place for new innovations.
I didn't find the inventor's name yet, and couldn't double check the facts.
One depends on the other. If C struct gets a new field, make it a Rust warning, not compile error.
Then Rust is checked, and warning goes away. Thus child API should not block
parent layer API development.
Enable easily add C function argument, and do the same into Rust API.
Either convert into a compile warning, or make it easy to adapt Rust code for the change.
Rust Developer words and actions do not align
This is where "unsafe" blocks come into play. They are misnamed. They should be called "manually-checked-for-safety-soundness" blocks.
Every time something at the C side API semantics changes the corresponding Rust unsafe blocks have to be checked whether some assumptions are broken.
Rust-C-bindings usually (have to) depend on the C side giving certain guarantees to the Rust code that are not expressible in the C type system.
If the C developer does not have that knowledge, it's actually better if she does not touch the unsafe blocks. It's very easy to introduce bugs there.
C-only developer breaks the API and provides details about the new semantics to the R4L people and they will fix the binding. These things have to be written down anyway for the C consumers of the API.
Rust Developer words and actions do not align
Rust Developer words and actions do not align
which call libraries. Soundness need to be maintained.
Ok, so the underlying library change (C library version bump up in user space)
need to be checked.
keeping audience awake. While learning, sometimes those need to be manually checked using piano.
Perhaps from the author himself, herself, if unsure about note or word.
don't do anything, until we have checked it.
and practically via abstractions, without modifying upper level library,
then the maintenance of lower level library is more practical.
Author is used to test code by compiling and running it.
So minimizing this kind of tight coupling could
improve productivity. Documentation advances?
Remaining cases: better tooling could be considered.
for program robustness. C held that position before. It took it from assembly language.
Thus it is good to not lower that baseline either.
and then retry, or meet face to face at a right time.
Shrinking productivity gaps, when identified: no need to wait for those.
Rust Developer words and actions do not align
Wol
Rust Developer words and actions do not align
Rust Developer words and actions do not align
Patches were dropped from this merge window because of Rust
x86/kgdb: use IS_ERR_PCPU() macro
compiler.h: introduce TYPEOF_UNQUAL() macro
percpu: use TYPEOF_UNQUAL() in variable declarations
percpu: use TYPEOF_UNQUAL() in *_cpu_ptr() accessors
percpu: repurpose __percpu tag as a named address space qualifier
percpu/x86: enable strict percpu checks via named AS qualifiers
Not quite "No interesting drivers"...
Ageism aside
Ageism aside
And if you do want a formal specification for things like certification efforts, there's the Ferrocene specification, which is an output artifact from Ferrocene's efforts to produce a qualified version of the open-source Rust compiler you can pay for if you need to prove that you meet various software safety standards.
Formal specification for Rust
Well, apparently now this situation has now resulted in Hector Martin resigning—apparently after he first instigated some social media "brigading" of some sort.
Hector Martin resigned