LWN: Comments on "A change in maintenance for the kernel's DMA-mapping layer"

Rust will not reduce platforms

edgewood — Wed, 05 Mar 2025 00:59:51 +0000

Are there kernel architectures that are not supported by Rust that can support new devices in need of new drivers? My understanding is that all but one of the kernel architectures not supported by Rust are legacy architectures that are out of manufacturing. Are they really getting new devices? Can you point me to a concrete example of one of these?

Use of unsafe in kernel Rust code

farnz — Tue, 04 Mar 2025 10:23:12 +0000

You may have to weaken it as compared to #![forbid(unsafe_code)], but that's still a lot stronger than you get from plain C. Bubbling up unsafe to a high level is absolutely fine, though - it just tells callers that there's safety promises that Rust can't check, but relies on you checking manually instead.

And even in the kernel, the hard distinction makes a lot of sense; the point of unsafe is that the "unsafe superpowers" allow you to cause "spooky action at a distance" by breaking the rules of the abstract machine. The core purpose of the unsafe/safe distinction is to separate out these two classes of code, so that you can focus review efforts on ensuring that unsafe code doesn't break the rules of the machine, and hence that bugs can be found by local reasoning around the area of code with a bug.

The problem that Unsafe Rust and C both share is that a bug doesn't have to have local symptoms; for example, a bug in an in-kernel cipher used for MACsec can result in corruption of another process's VMA structures, causing the damaged process to crash for no apparent reason. That means that you have to understand the entire codebase to be certain of finding the cause of a bug; Safe Rust at least constrains the impact of a bug in the code to the things that code is supposed to be touching, so you can (e.g.) rule out all parts of the Safe Rust codebase that don't touch VMAs if what you're seeing is a corrupt VMA.

Use of unsafe in kernel Rust code

magnus — Tue, 04 Mar 2025 03:50:28 +0000

The point i am trying to make is that you may not always be able to completely encapsulate the unsafe code into safe abstractions but have to propagate it upward in some way, either by going up the call stack and making all users of the abstraction unsafe or by lying to the compiler that your abstraction is safe but then requiring the additional constraints to be managed by the callers outside of the type system. So you may be forced to weaken the idea of "safe by construction" a little bit.

For example if the ownership or concurrency management of something central like a struct page or something depends on a lot of tangled state that the Rust compiler can not verify you can create abstractions that modify it but then you also require that the other conditions are satisfied. If they are called at the wrong time they would still compile but yield unsafe behavior.

On the other hand the hard distinction between safe/unsafe and logic bug may not make much sense deep in the kernel anyway as any logic bug would be both a safety and functional issue.

Use of unsafe in kernel Rust code

farnz — Mon, 03 Mar 2025 12:02:25 +0000

The goal isn't to remove unsafe completely when you're writing a kernel; rather, you want to constrain it to small chunks of code that are easily verified by a human reader. For example, it's completely reasonable to require unsafe when you're changing paging related registers, since you're changing something underneath yourself that the compiler cannot check, and that can completely break all the safety promises Rust has verified.

It does tend to be true in practice that you can encapsulate your unsafe blocks behind zero-overhead safe abstractions (e.g. having a lock type that is unsafe to construct because it depends on all CPUs running kernel code, not userspace), but that's an observation about code, not a requirement to benefit; even without that encapsulation, you benefit by reducing the scope of unsafe blocks so that it's easier to verify the remaining bits.

A prediction with no data to support it

laarmen — Mon, 03 Mar 2025 11:23:01 +0000

> but I just wonder if there are situations in the kernel that can not be nicely contained in Rust abstractions with unsafe code and safe before/after points.

I'm pretty sure such situations will come up, but I don't see this as a problem. Again, the goal is not to avoid `unsafe` entirely. The entire point of `unsafe` is to have a way to communicate that there are invariants that cannot be upheld by the compilers that guarantee the safety of operations that are in general not safe.

Rust will not reduce platforms

taladar — Mon, 03 Mar 2025 10:24:15 +0000

The real question is why do those niche platforms have such an overwhelming impact on Linux development decisions despite largely being out of production for decades?

Assume good faith, please

corbet — Sun, 02 Mar 2025 00:51:29 +0000

Wol, I have asked you this before. Please assume good faith on the part of the developers involved in these discussions. Please do not attribute such base and cowardly motives to people who have worked for years to build the kernel you use and who are concerned about its ongoing maintenance. The people who are worried about Rust may well turn out to be wrong (I suspect they will), but they are not driven by fear of developers who can write a driver faster than they can. Seriously. That kind of stuff just makes the conversation harder for no good purpose.

Well

Wol — Sun, 02 Mar 2025 00:41:22 +0000

> But this way is bass-ackwards and reeks of disingenuineness. Be honest about your intentions and goals up front, because the *only* logical outcome of this entire effort is Rust-in-the-core-kernel and completely deprecating (new) C. Anything less is gives you the worst of both worlds.

If you want honsety, don't accuse others of dishonesty! There's far too many people who take the attitude "I've made up my mind, i don't care about the facts!". What's that saying? "What you see in others is a mirror of yourself"?

I'll be honest with you - I suspect that what you claim will turn out to be the future. I do NOT think that is the aim of this "Rust in the kernel" experiment, I just expect it will be what ends up happening. Because when people realise they can write a mostly-bug-free driver in Rust in two weeks, but it takes two years to write a similar driver in C, they will refuse to use C.

Which is why the Rust refuse-niks are making such a fuss. They can see the writing on the wall just as clearly as you or me, and they don't want that future.

Cheers,
Wol

Well

khim — Sat, 01 Mar 2025 22:57:20 +0000

> Meanwhile, Rust, in of itself, does not force anything of the sort

It kinda-sorta does. Lifetime markup may be perceived as part of the code, but in reality it's the documentation.

Proof: mrustc ignores it yet generates valid code.

What I find really strange is such an active resistance to it. Linux was doing that same thing for years with sparse.

Rust just turns that same thing (that was part of Linux development process for more than 20 years!) “up to eleven”.

Well

raven667 — Sat, 01 Mar 2025 22:37:05 +0000

> because the *only* logical outcome of this entire effort is Rust-in-the-core-kernel and completely deprecating (new) C. Anything less is gives you the worst of both worlds.

I don't think this is accurate, it's not that black and white, either/or, win/lose, I would take it at face value that introducing Rust to the kernel is a hopeful experiment and that new drivers can be written in C or Rust and that while Rust is experimental that Rust maintainers would be responsible for keeping it in synch with other kernel interfaces as they change, not just the person making interface changes. I would expect that both styles will coexist for a long time and that only if the predominant consensus of the kernel developer community changes would new work in C be *forbidden*. Even after Rust is no longer experimental I think that there is still going to be a long period where predominantly Rust developers will be needed to maintain internal bindings and wrappers for the predominantly C core, and having C developers update Rust bindings depends on how many see value in spending time learning Rust.

Rust will not reduce platforms

mfuzzey — Sat, 01 Mar 2025 18:32:58 +0000

Drivers are generally *hardware* dependent (of course) but most are *platform* independent.

This applies to virtually all drivers for hardware that isn't in the SoC itself (eg chips connected to the CPU using busses like I2C / SPI / PCI / USB ).

Even when the hardware is actually inside the SoC it's quite common for IP blocks to be reused in multiple SoCs, even ones from different manufacturers (because manufacturers often buy the IP for an ethernet controller, USB controller or whatever and integrate it in their SoC). In that case the register interface is the same so the driver code is the same but the registers will be at different addresses (and that's taken care of by injecting the appropriate base address by DT / ACPI)

So, in many cases, having drivers in Rust will impact Linux support for platforms that don't yet have a Rust implementation. And while it is indeed possible to have competing implementations this usually frowned upon in the kernel for duplication / maintenance reasons and usually exists only temporarilly.

Not all delay is bad

corbet — Fri, 28 Feb 2025 19:59:58 +0000

The "Rust video drivers" are not part of any kernel release at this point, how would you expect them to accumulate CVEs? Please, arguing for the sake of argument doesn't help anybody.

Not all delay is bad

Wol — Fri, 28 Feb 2025 19:43:12 +0000

> But another part of it could easily be to give Rust more time to prove its worth (or lack). For example, meaningful metrics on CVE/bug counts correlated to changes due to adding Rust (whether it's drivers being written in it or API correctness fixes/documentation to support it) would have a significant impact on the discussion.

"Don't let the facts spoil a good argument". I think we already have those metrics.

The Rust video driver(s) have pretty much 0 CVEs I believe, and were written in much less time than equivalent C drivers. I expect the stats will be the same for other Rust drivers.

Cheers,
Wol

Not all delay is bad

draco — Fri, 28 Feb 2025 19:27:44 +0000

IMO, it's definitely about pushing the conflict over Rust to later, but I don't think it's as simple as conflict avoidance. I'm sure that's a part of it—after all, if every maintainer quit all at once, it would definitely be very disruptive (not necessarily fatal—Linux is too important to the industry to just let it fail outright). If tweaking the rules to appease them solves the problem for now, great!

But another part of it could easily be to give Rust more time to prove its worth (or lack). For example, meaningful metrics on CVE/bug counts correlated to changes due to adding Rust (whether it's drivers being written in it or API correctness fixes/documentation to support it) would have a significant impact on the discussion. Or improvements in review bandwidth for maintainers that decide to embrace it, or the lack of that. Or coming through with better platform support and feature stabilization (or not).

It's okay to delay arguments if doing so gives everyone better information & circumstances and doesn't make things substantially worse in the meantime. It's avoidance for the sake of it while letting things get worse (the typical situation) that's bad.

Well

pizza — Fri, 28 Feb 2025 19:23:48 +0000

> At which they failed miserably. Rust *FORCES* you to document your interfaces.

(Funny you say that. Linux is routinely held up as the most successful software engineering project of all time, in no small part due to the development methodology and processes that you're calling a miserable failure)

Meanwhile, Rust, in of itself, does not force anything of the sort; One can easily commit all manner of horrible sins with Rust. What gets committed depends on what the project considers acceptable. The same goes for interface documentation.

If Linus wants to change the development model/processes of Linux, then he needs to be explicit about it, and the discussion can revolve around the pros and cons of those changes, and from there the pros/cons of various approaches.

But this way is bass-ackwards and reeks of disingenuineness. Be honest about your intentions and goals up front, because the *only* logical outcome of this entire effort is Rust-in-the-core-kernel and completely deprecating (new) C. Anything less is gives you the worst of both worlds.

rust?

draco — Fri, 28 Feb 2025 18:34:43 +0000

Umm, reread the quoted text again.

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

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

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

Well

Wol — Fri, 28 Feb 2025 17:41:09 +0000

> If those "reassurances" are true, they represent a _massive_ change to how the process of development and maintainership is supposed to work.

I think you're right ... (not the way you think you are)

> The (now-former) processes weren't arbitrary; they were carefully honed and battle-tested in no small part to prevent "issues down the line".

At which they failed miserably. Rust *FORCES* you to document your interfaces. The fact this is not true of C leads to the steady stream of CVEs and exploits all C projects seem to suffer from, as people on both sides of the interface mis-understand each other (and you can see that here in this storm).

Linus has learned that not documenting things is costly. I know that writing good documentation is difficult (and costly) - I can understand people not wanting to do it. Unfortunately, the attitude of "I know what I'm doing, why do I need to tell other people" is no longer acceptable. I've spent most of today getting extremely frustrated with (a) users who can't explain what they want, and (b) Excel formulae which can't explain what they're doing! Oh for some decent documentation! Excel actively frustrates attempts at decent documentation!

At the end of the day, Christoph has paid the price for not working well with others. Linus has always been a good people manager, and maybe he's now realising that prima donnas are more trouble than they're worth (or maybe he always knew that, he may just be being forced to face up to it).

Cheers,
Wol

A prediction with no data to support it

magnus — Fri, 28 Feb 2025 17:23:08 +0000

Thanks for the answer and sorry for harping on but I just wonder if there are situations in the kernel that can not be nicely contained in Rust abstractions with unsafe code and safe before/after points. Like situations where you can safely act on shared data without locking because you know that the overall state of the system is such that you cant have races but you cant describe it with Rust features. Maybe in scheduler code you might know that all the cpus got interrupted and you know what code the others are executing (as they are all running the same kernel code).

rust?

Wol — Fri, 28 Feb 2025 15:44:25 +0000

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

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

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

Cheers,
Wol

rust?

mathstuf — Fri, 28 Feb 2025 14:06:08 +0000

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

Architecture, microarchitecture, and undefined behaviour

mathstuf — Fri, 28 Feb 2025 14:01:21 +0000

> in C++ undefined behaviour is reportedly allowed to time-travel.

This has been argued, but it seems that no one has been able to show an instance of a compiler actually doing so. There are some solutions for it in the works (by saying "it's not allowed"), but it is practically an no-op as compiler have already behaved that way (though I am certainly not well-steeped in the matter for the details):

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/...

Well

pizza — Fri, 28 Feb 2025 13:30:32 +0000

> I suspect he didn't believe the reassurances were real, just a way to placate things and postpone the issues down the line.

This is my take too.

...Replace the word "Rust" with anything else, and there's a long, long, long history of Linus utterly flaming folks for it.

If those "reassurances" are true, they represent a _massive_ change to how the process of development and maintainership is supposed to work. The (now-former) processes weren't arbitrary; they were carefully honed and battle-tested in no small part to prevent "issues down the line".

rust?

LtWorf — Fri, 28 Feb 2025 12:17:34 +0000

> when the same may happen to C people.

It is happening to C people…

Well

LtWorf — Fri, 28 Feb 2025 11:58:00 +0000

I suspect he didn't believe the reassurances were real, just a way to placate things and postpone the issues down the line.

rust?

amarao — Fri, 28 Feb 2025 11:49:43 +0000

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

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

rust?

LtWorf — Fri, 28 Feb 2025 11:46:54 +0000

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

True. The alternative being quitting. Which he did.

A prediction with no data to support it

anton — Fri, 28 Feb 2025 09:18:54 +0000

E.g. on x86 there's the BSF/BSR instructions ("If the content of the source operand is 0, the content of the destination operand is undefined"). Many instructions leave flags in an undefined state. With memory accesses to I/O address space, "The exact order of bus cycles used to access unaligned ports is undefined". Running the same machine code on different CPUs can give different behaviour, in the same way that running the same C code through different compilers (or the same compiler with different optimisation flags) can give different behaviour, with no documentation of what will happen, so I think it's reasonable to equate that to C's concept of UB.
(And the C standard says UB specifically means "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements", so it's not literally dependent on there being an optimising compiler.)

C language lawyers make a fine-grained difference between different forms of lack of specification in the C standard. IIRC they have "unspecified value" for cases where the result of an operation is unspecified (as in the BSF/BSR case and the unspecified flags results). I think they do not have a special name for an unspecified order.

And while I agree with the idea that the C standards committee originally used "undefined behaviour" for cases where different implementations produced different behaviour, and where they did not have a more specific term (such as "unspecified value"), for several decades C compiler writers have used "undefined behaviour" to assume that this behaviour does not occur in the programs they support (unless the program is "relevant" for some reason), and there are people around that advocate the position that this has been the intent of "undefined behaviour" from the start.

And the latter form of "undefined behaviour" has quite different results from the former; e.g., with the latter form a loop with an out-of-bounds access can be "optimized" into an endless loop, while with the former form it will perform the memory access, either giving a result, or producing something like a SIGSEGV.

In practice, all the undefined/unpredictable CPU behaviour that's accessible from userspace is probably documented internally by Intel/Arm for backward compatibility and security reasons

Especially backwards-compatibility; the security benefits fall out from that. As for the bad design in the ARM architectures, maybe they have had too much contact with compiler people and become infected by them. I expect that at some point the implementors of ARM architectures will find that existing programs break when they implement some of the ARM-undefined behaviour in a way different than earlier implementations of that architecture, and that behaviour then becomes an unofficial part of the architecture, as for the Intel and AMD cases mentioned above. A well-designed architecture avoids this pitfall from the start.

A prediction with no data to support it

taladar — Fri, 28 Feb 2025 08:55:28 +0000

UB is not really just a single undefined operation, it is more what happens as a consequence of relying on an invariant the optimizer assumes that then gets broken, e.g. you could have a piece of code that relies on the invariant that an enum discriminant is only ever 0, 1 or 2 and optimizes a jump to go to a base address plus the discriminant multiplied by 8 without checking bounds so if that invariant is broken you end up literally jumping to memory that could have any kind of code and so the behavior is undefined and could launch missiles for all we know.

rust?

taladar — Fri, 28 Feb 2025 08:48:39 +0000

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

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

Architecture, microarchitecture, and undefined behaviour

anton — Fri, 28 Feb 2025 08:24:01 +0000

So what are the semantics if you corrupt the stack and as a consequence jump to uninitialized memory or memory that you intentionally filled with random data to construct a key or even worse, memory filled by data controlled by an attacker. By the very definition of the instruction set anything can happen.

Not at all. First of all, the architectural effects of every instruction up to that point continue to hold, while, e.g., in C++ undefined behaviour is reportedly allowed to time-travel. Next, in a well-designed architecture what happens then is defined by the actual content of the memory and the architecture description, which does not contain undefined behaviour (remember, we are discussing well-designed architectures). Maybe you as programmer do not deem it worth reasoning about this case and just want to put the label "undefined behaviour" on it, but as far as the architecture is concerned, the behaviour is defined.

An optimizing out-of-order architecture in the CPU.

The architecture does not specify out-of-order execution, on the contrary, it specifies that each instruction is executed one by one. There may be a microarchitecture with out-of-order execution like the Pentium Pro below it, or a microarchitecture with in-order execution like the 486, but the end result of executing a sequence of instructions is the same (except for the few cases where the architectures differ; IIRC the CMOVcc instructions were in the Pentium Pro, but not the 486).

And this [micro]architecture makes similar assumptions on what can happen vs. what cannot happen. And again, you can call this behavior by different names, but it is essentially undefined.

Computer architects have learned what later became Hyrum's law long ago, and therefore define completely (or almost completely for not-so-well designed architectures) what happens under what circumstances. Microarchitectures implement the architectures, and they do not assume that something cannot happen when it actually can. When the microarchitects fail at implementing the architecture, as with Zenbleed, that's a bug.

The CPU does not have the global sense of what is going on as the compiler, but messing up locally is enough to corrupt your data.

Microarchitectures with out-of-order execution do not commit any changes that do not become architectural, and therefore do not corrupt data (rare architecture-implementation bugs like Zenbleed excepted).

A prediction with no data to support it

rgmoore — Fri, 28 Feb 2025 00:37:21 +0000

In fact, the Linux kernel is one of the projects written in C and assembly. It doesn't run into the multi-language problem because the assembly is restricted to places where C is impractical, and nobody is threatening to rip out functioning C code to replace it with assembly.

rust?

Wol — Thu, 27 Feb 2025 14:53:28 +0000

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

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

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

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

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

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

Cheers,

Wol

rust?

amarao — Thu, 27 Feb 2025 14:04:20 +0000

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

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

rust?

daroc — Thu, 27 Feb 2025 13:34:50 +0000

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

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

A prediction with no data to support it

excors — Thu, 27 Feb 2025 12:31:54 +0000

> UB specifically means "an optimizing compiler is allowed to assume that this never happens." It cannot exist at the machine code level, because there is no compiler. The closest we can get (within the context of the C and C++ standards) is implementation-defined behavior, which roughly translates from the standardese to "if this happens, we don't know what your system will do, but you can read your compiler, CPU, and OS manuals and figure it out if you really want to."

I don't think that's really true. x86 and Arm have a number of things that are explicitly documented as "undefined" or "unpredictable" in the architecture references, and are not documented in CPU-specific manuals (as far as I can see), so you can't figure out the behaviour even if you really want to.

E.g. on x86 there's the BSF/BSR instructions ("If the content of the source operand is 0, the content of the destination operand is undefined"). Many instructions leave flags in an undefined state. With memory accesses to I/O address space, "The exact order of bus cycles used to access unaligned ports is undefined". Running the same machine code on different CPUs can give different behaviour, in the same way that running the same C code through different compilers (or the same compiler with different optimisation flags) can give different behaviour, with no documentation of what will happen, so I think it's reasonable to equate that to C's concept of UB.

(And the C standard says UB specifically means "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements", so it's not literally dependent on there being an optimising compiler.)

In practice, all the undefined/unpredictable CPU behaviour that's accessible from userspace is probably documented internally by Intel/Arm for backward compatibility and security reasons, since the CPU is designed to run untrusted machine code (unlike C compilers, which are designed to compile only trusted code). Armv8-A has a lot of "constrained unpredictable", where it's documented that an instruction might e.g. raise an exception or be treated as NOP or set the destination register to an unknown value but it isn't allowed to have any other side effects; but there's still plenty of non-constrained "unpredictable" behaviours. They're not fully unconstrained: they are documented as obeying privilege levels, but they can have arbitrary behaviour that would be achievable by any code within that privilege level, which is the same as C's UB in practice (e.g. UB in an application is not allowed to break the kernel). So I think it's very much like C's UB.

A sincere thank-you to Christoph for years of hard work in a difficult and critical area

taladar — Thu, 27 Feb 2025 11:59:49 +0000

Sounds to me like the exact kind of code where investing in better tooling and language features would be a good idea.

rust?

amarao — Thu, 27 Feb 2025 11:54:33 +0000

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

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

Or maybe ...

CChittleborough — Thu, 27 Feb 2025 11:27:05 +0000

Perhaps Mr Hellwig was prompted by recent events to re-assess his current lifestyle, and decided to reduce his workload? If so, good on him.

Humans have a tendency to leap to negative conclusions. We should all fight that tendency.

rust?

mathstuf — Thu, 27 Feb 2025 11:21:46 +0000

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

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

rust?

Wol — Thu, 27 Feb 2025 11:00:03 +0000

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

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

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

Cheers,
Wol