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)
In reply to: How will cooperation of rust-knowing and not-rust-knowing maintainers look like? by gray_-_wolf
Parent article: The Rust for Linux project

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.