Comment by llm_trw
10 months ago
What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
10 months ago
What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
And what if they do care, but they simultaneously need features available in multiple different forks? You can't run two kernels at the same time.
Then it means the rust code does impact the C code and the rust people were lying.
That doesn't make sense, and you can look at the patches and see that the Rust code didn't impact the C code. It's not like we have to take anybody's word for it.
This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two.
"Just fork it" doesn't work here. It's a logistical nightmare.
1 reply →
"if you match upstream"
Talk about aggressively missing the point.
Explain what the point is.
Rust developers are promising that rust in the kernel should have no impact on c in the kernel.
If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.