3 ms·
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.
by llm_trw 2y 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.
- dralley 2y ago"if you match upstream" Talk about aggressively missing the point.
- llm_trw 2y agoExplain 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.
- MyOutfitIsVague 2y agoAnd 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.
- llm_trw 2y agoThen it means the rust code does impact the C code and the rust people were lying.
- MyOutfitIsVague 2y agoThat 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.
- uecker 2y ago"not forking" is much better exactly because a lot of the maintainance and integration work is then distributed on the existing maintainers.