Exactly. And as far as I understood the talk, nobody even asked the audience to change their ways. Now, as mentioned by the presenter himself, refactors that c

Exactly. And as far as I understood the talk, nobody even asked the audience to change their ways. Now, as mentioned by the presenter himself, refactors that change the API semantics will break any consuming code, no matter if written in Rust or C. So, one option is that the whole issue around breaking Rust bindings is just a strawman and the vocal part of the audience just wants Rust devs to gtfo. In the other, more charitable setting I can conceive, we are looking at an API that isn't extensively documented in the first place (obviously, otherwhise the Rust for Linux team wouldn't have to ask for clarification) and a small group of kernel devs who are trying to fix everything by themselves rather than documenting changes in a way that so other people can fix their own API-consuming code. In this setting, also fresh would-be contributors using C will have a hard time getting to grips with the codebase. Now, if I remember correctly, one of the purported reasons for Linux to open up to Rust was to attract fresh developers, but in the outlined scenario, there is a clear reason why people might bounce off, and it is unrelated to the language (at least if this case is representative for other parts of the kernel codebase). None of the options look good to me. But perhaps I am just missing something.