Is a kernel developer blocking the success of Rust for Linux? Yes and no!

Contents

A maintainer of the Linux kernel recently refused to include Rust code in his territory, which is essential for many drivers – thus apparently dooming the efforts to use Rust to program more than just simple Linux drivers in the future. At least that is the impression given by numerous reports on Linux news sites and statements in forums or on social media platforms.

Two things usually fall by the wayside: this kind of banter is more common in Linux development – and solutions are usually found sooner rather than later that all those involved – can live with, if necessary, with gritted teeth –. This is also to be expected here. The backing that the numerous central and long-established kernel developers give to the Rust for Linux efforts – Torvalds included, should ensure this.

Blockade of code for an essential technology

The current uproar has been triggered by statements from the maintainer of Linux's DMA mapping helper code, Christoph Hellwig: he has rejected the inclusion of changes to use Direct Memory Access (DMA) in drivers written in Rust – a technology that has been essential for proper performance for decades and saves the processor a considerable amount of work. Hellwig called on developers to integrate the code directly into Rust drivers instead – but this makes maintenance more difficult for other developers and contradicts modern code design practices.

In the course of the discussion, which has been ongoing since the second week of January, Hellwig later emphasized that he had no interest in dealing with code written in several programming languages – and mentioned that this applied to assembler just as much as to Rust. He also rejected the suggestion that the DMA Rust code should be stored separately and maintained by someone else; he also spoke out very harshly against allowing Rust code to penetrate central areas of the kernel.

The Linux kernel is actually not one project, but hundreds

The discussion between the developers recently flared up again after LWN reported on it. There is no amicable solution in sight. Disputes like this have already occurred dozens of times in Linux development on other topics. No wonder because what the outside world sees as a kernel is actually more than a hundred principalities under the aegis of Linus Torvalds.

Although the princes work together on bigger things, they have far-reaching sovereignty over their area –. A code formatting, bug report or patch submission that is correct for one subsystem may be rejected as fundamentally wrong for another. Naturally, the various subsystem maintainers also disagree from time to time about the big picture and the interaction between the different areas, which leads to disputes such as the current one.

When in doubt, Torvalds decides

Sometimes the princes play tricks to get around a blockade of another subsystem. Sometimes this works with a bit of brute force on the part of those involved, but sometimes it comes to blows. When in doubt, Linus Torvalds sooner or later puts his foot down – either for real or by accepting code against the express will of a maintainer.

In the worst-case scenario, the maintainer packs his bags, but this rarely happens. The last major conflict of this kind was the extensible process scheduler, which the maintainers of the process scheduler resisted for a long time – until Torvalds let it be known that he would accept the code in the medium term anyway. This happened over a year later with Linux 6.12.

An outcome of this kind is also likely in the current conflict. Until this happens, however, Torvalds usually stays out of public discussions – so it is no wonder that he has not responded to a request for a statement on the Rust DMA issue.

It is therefore quite possible that the current conflict will continue to smoulder until a driver that relies on DMA and is written in Rust is to be incorporated into the kernel or until their number increases. However, the former could soon be the case: A Red Hat developer has just submitted the first parts of the Nova graphics driver written in Rust for integration, which supports modern Nvidia GPUs and is intended to replace the “Nouveau” driver. DMA is essential for this driver.

Subsystem maintainers are often already under high pressure

Incidentally, be careful with hasty classifications of blockages such as those of the Rust DMA code: There are often hidden reasons for this. Many subsystem maintainers, for example, are hopelessly overworked because their employer gives them very little time to look after the upstream code; there are also many maintainers who do the job entirely in their free time. For many, the boundaries between working hours and free time are blurred.

It is therefore understandable that maintainers resist changes that could lead to interpersonal problems, complicate the warnings or further increase the workload for no good reason. This includes, for example, closer collaboration with perhaps unloved or unknown developers as co-maintainers – or code in another programming language that the respective subsystem maintainer does not know and cannot or does not want to learn in an evening. In addition, such code can also make planned conversions impossible or significantly more difficult.

Insights into disputes that remain secret elsewhere

Sometimes such blockades are therefore just levers to draw more attention to problems or to get other players to release funds to alleviate them. This also happens in the development of kernels for macOS or Windows, but behind closed doors within the company. But in the end, the same applies here as there: many things are not eaten as hot as they were previously cooked.

(olb)