How will cooperation of rust-knowing and not-rust-knowing maintainers look like? [LWN.net]

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 9:28 UTC (Fri) by gray_-_wolf (subscriber, #131074)
Parent article: The Rust for Linux project

Hm, I still don't understand how the "at first work only with subsystems/maintainers that are interested" is supposed to work. Admittedly, I do not know much about linux development, but from the articles and comments on this site my understanding is that lot (some?) of the changes require some modifications even in other subsystems, even if your main patch is focused on one.

If the other subsystem is (partially) in rust, which you do not know, how would that be handled? If some parts of your patch touch some rust code, but goes via a tree of a maintainers that does not know rust, how should that be handled?

Just to make it clear, I really am just trying to understand how this will (would?) work. These are really obvious questions, so I've likely just overlooked it already being discussed somewhere.

to post comments

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 9:47 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (4 responses)

There are some subsystems which are very central and would be "forcibly" made part of the Rust effort, because their API would have Rust-to-C bindings. Changing APIs in those subsystems would require changes to the bindings. This is for example the case for VFS, where Rust drivers may have to define file_operations (hence my question to Miguel, that the article refers to).

But apart from that, for something such as drivers (which are the initial focus of the project), the cases of patches affecting multiple subsystems are quite rare.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 15:21 UTC (Fri) by broonie (subscriber, #7078) [Link] (3 responses)

You'd be surprised how many drivers interact with multiple subsystems - for example it's very common to consume multiple APIs for resources like control bus, clocks, regulators and GPIOs while also offering another API to their own users. The whole thing about drivers not needing to interact with much is very much an assumption based on server type systems.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 15:56 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (2 responses)

I understand, the simplest case being a SCSI adapter sitting on a PCI bus. Such a driver obviously would need Rust bindings to both subsystems. But it's rare for drivers to "require some modifications even in other subsystems" (quoting the message I replied to). Usually driver changes are fairly self-contained.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 18, 2021 8:24 UTC (Sat) by matthias (subscriber, #94967) [Link] (1 responses)

It is not the driver requiring changes to the subsystems that gray wolf and broonie are talking about, but the other direction. I.e., a change to the subsystem that requires all users to be adapted. In this case the maintainer of the subsystem has to adapt the rust wrapper for the C API.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 18, 2021 18:32 UTC (Sat) by broonie (subscriber, #7078) [Link]

Right, and especially drivers needing some new subsystem improvements to cope with some new feature or usage pattern that the hardware has - this is especially true for things not on standardised buses (or not entirely) where it’s much easier for hardware to do new things.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 16:41 UTC (Fri) by ojeda (subscriber, #143370) [Link] (1 responses)

> my understanding is that lot (some?) of the changes require some modifications even in other subsystem

No, they don't. At the moment, the Rust side is a client of the C APIs, and thus the modifications to the C side are minimal.

The problem is that, even in this case, if you are doing subsystem or tree-wide changes that change C APIs, and they happen to be used by Rust code, then you would also need to update those.

This is what some kernel maintainers/developers that regularly do those kind of changes are worried about -- they would need to learn Rust fairly soon, which may put a big burden on them. Thus we may need to have a way to smooth things for them (e.g. relaxing the rules, helping them write or review the Rust side of the code, etc.).

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 16:58 UTC (Fri) by ojeda (subscriber, #143370) [Link]

> No, they don't. At the moment, the Rust side is a client of the C APIs, and thus the modifications to the C side are minimal.

Ignore this sentence -- I thought you were referring to the Rust changes. For kernel changes in general, yes, some of them change different places in the kernel (the second part of the comment addresses that).

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

Posted Sep 17, 2021 19:00 UTC (Fri) by ojeda (subscriber, #143370) [Link]

> These are really obvious questions, so I've likely just overlooked it already being discussed somewhere.

No, I don't think you overlooked :) We have talked about these points a few times, but they are still quite open. At LPC next week we will try to have this discussion with more kernel maintainers.