Comment by dralley
3 days ago
>Presumably, this is an investment in replacing code written in C. There's no way around abstraction or overhead in such a venture.
Nobody is proposing replacing code right now. Maybe that will happen eventually, but it's off limits for now.
R4L is about new drivers. Not even kernel subsystems, just drivers, and only new ones. IIRC there is a rule against having duplicate drivers for the same hardware. I suppose it's possible to rewrite a driver in-place, but I doubt anyone plans to do that.
There is a binder driver rewrite in rust. Companies who care are certainly rewriting drivers. If there is pushback in upstreaming them that will cause a lot of noise.
[flagged]
> Why not? That's the really juicy part of the pitch.
For now, it's because for logistical and coordination reasons, Rust code is allowed to be broken by changes to C code. If subsystems (especially important ones) get rewritten in Rust, that policy cannot hold.
> yes i get there are linux vets we need to be tender with. This shouldn't obstruct what gets committed.
Not sure why you believe that. We're not all robots. People need to work together, and pissing people off is not a way to facilitate that.
> if this is what linux conflict resolution looks like, how the hell did the community get anything done for the last thirty years?
Given that they've gotten a ton done in 30 years, I would suggest that either a) your understanding of their conflict-resolution process is wrong, or b) your assertion that this conflict-resolution process doesn't work is wrong.
I would suggest you re-check your assumptions.
> You quarter-assed this reply so I'm sure your next one's gonna be a banger.
Please don't do this here. There's no reason to act like this, and it's not constructive, productive, interesting, or useful.
[flagged]
1 reply →