I did, I'm actually puzzled he referenced this.
You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.
That this discussion repeats itself can only be taken to be either:
1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo!
2) The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions:
* Who tests to avoid this?
* Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
* Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
* What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also.
In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.
That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.
You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.
That this discussion repeats itself can only be taken to be either:
1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo!
2) The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions:
* Who tests to avoid this?
* Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
* Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
* What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.
That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.