A change in maintenance for the kernel's DMA-mapping layer

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

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

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

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

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

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

"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

That does cause a bit of friction when some parts of the C++ standard library and language are designed around the assumption that you have exceptions, but in practice it works okay (or at least it's no more problematic than several other aspects of C++).

I can't imagine the Linux kernel actually adopting C++ though, because it would have pretty much all the same technical challenges and cultural pushback as Rust, with significantly fewer benefits to make it seem worthwhile.

It like "oh well, just ship this code or release it into production because the catch all exception handler will handle the problem and the user can either try again or we can fix any issue we find or someone reports after the fact in a month or two or maybe sooner if it is really serious." And that is if the problem ever gets fixed at all, within the lifetime of the project, the product, the service, the volunteers (where applicable), managers, leaders, or the developers in question.

I used to write video games in C and assembly language and in my view good code should perform according to specification and be usable a century from now if committed to ROM and sold on store shelves or shipped in products that way. Does anyone doubt that most Nintendo, Sega, or Atari 7800 games will actually work with the appropriate hardware without major malfunctions decades from now? What about something like Netware (which was originally mostly written in 80386 assembly language) or the Amiga operating system (originally written in a mixture of C, BCPL, and 68K assembly language) or a number of other things, at least if deployed into a non-hostile environment?

You can see this problem in web applications written in Javascript all the time these days, especially on the web sites of banks that are not among the largest in the country or on the websites of most non-bank credit card issuers and lenders as well. I use websites on a regular basis where it is a fifty fifty chance that a login with the correct credentials supplied will actually succeed. And that goes for many other actions as well where the user is often required to do things like put in their credit card information to make a payment twice because of mysterious error occured problems that are cured simply by repeating the process. Or worse where a payment will not go through at all for weeks for other and never documented reasons not explained to the user. There is a major funds transfer webapp whose name you would all recognize that often behaves that way these days.

I believe that this is likely and in large part the result of libraries and code included in many modern Javascript applications that is are so extensive that either the exceptions are undocumented or you have to be an expert to handle them properly, and often entry level developers are not given enough time or resources to fix the problem. That is my experience for a few years when I was in the unfortunate position of having to maintain and develop code for a moderately sophisticated web application that was originally programmed to use Javascript only where necessary. When you have a dozen or more developers working on a project it is that much worse.

Anyway I am not surprised that a large team has a difficult time writing safe, correct, and decently performing C, C++, or Java code and don't really see any solution to that other than compilers and static analysis tools that identify the problems and produce and optimize code better than most developers can write by hand even after they stare at a problem for hours at a time. And in a project as big as the Linux kernel or something like a modern database or web browsers in my view it would be worth it to write static analysis tools that are hard coded if necessary to describe and enforce the constraints and rules that govern and apply to that project. A more general tool would be nice but apparently no one has written one yet - not one capable or used enough (apparently) to find the memory safety, locking, and other problems that still make it to deployed production kernels and have to be corrected after the fact in some cases after making national or international news due to problems that ought to be straightforward to analyze and detect.

Finally, although this almost certainly could not be done well or perfectly without heavy use of a new series of #pragmas or language extensions, my idea of a usable C or C++ compiler for a large project is one that refuses to compile code with undefined behaviors at all and require the developer to supply machine architecture and memory model targeting information to make those behaviors implementation or configuration defined if he or she wants to code almost anything that would otherwise result in undefined behavior that developers, vendors, and publishers of contemporary C and C++ compilers feel like they have a license to do anything for any reason such as delete entire code sections or skip appropriate if statements and safety checks as we have read about here from time to time with regard to C compiler optimizers causing serious problems for that reason. That is my two cents on this question.

Today, where Rust is going in is the drivers. Drivers are often fairly platform specific already. You can also have competing drivers for the same hardware if it turns out that there needs to be a mainstream and a niche option. But the fact that Apple Silicon users are writing their GPU drivers in Rust is not going to threaten Linux support for my niche architecture.

Rust support is also being added to GCC (gccrs). That may take a while to bake but I expect it to mature before we start seeing Rust in core Linux systems that are non-optional across platforms. In other words, Rust in the kernel will not threaten platform support as long as your platform is supported by either GCC or Clang (LLVM).

What platforms are we worried about that cannot be targeted by GCC or Clang? Can Linux run there now?

As a final back-stop, their is mrustc. This allows Rust to target any system with a capable C++ compiler.

By the time Rust becomes non-optional in Linux, Rust will be as portable as C or C++.

Hm. Right now Rust is missing the following in-tree archs: sh, parisc, openrisc, nios2, microblaze, csky, arc, alpha.

Out of these architectures, only sh is still being manufactured. And maybe arc (from Synopsys). I'd be surprised if these architectures stay in-tree by the time Rust becomes mandatory. Except for Alpha, people love it for some reason.

Eggsackerly.

All you need is a properly defined API. And that's all the Rust guys were asking for. All I care about when using 3rd party code is that I have a definition of the interface I can comply with. Anything else is an opaque box I don't want to have to give a monkeys about.

Lack of such interfaces generally indicates badly designed (or implemented) spaghetti code. One only has to think back to Alan Cox and the tty drivers (okay, the younger linux kernel guys are probably too young to remember ... :-).

The more Rust makes people define their interfaces, the easier it will be to replace chunks of the kernel - with C++, PL/1, Basic, ... or Rust. Doesn't matter. The cleaner the boundaries, the easier it will be to replace bits.

Cheers,
Wol