Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust, and a Rust person will take care of it for them.
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
> Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust
So then the argument that even semantics encoded in the Rust types, can be out of the date compared to the actual code, is actually a real thing? I read that somewhere else here in the comments, but didn't understand how the types could ever be out-of-date, but this would explain that argument.
That's exactly what would happen "types get out of date". I'm not sure what you are familiar with. But imagine in python a new version of a library is released that now has an extra required argument on a function.
As I understand it everything Rust is seen as "optional", so a CONFIG_RUST=n build that succeeds means a-OK, then some Rust person will do a CONFIG_RUST=y build, see it's broken, fix it, and submit a patch.
I may be wrong, but that's how I understood it, but who knows how Linus will handle any given situation. ¯\_(ツ)_/¯
