3 ms·

> The staging tree is for sketchy code. If the code is likely to fail in weird ways for reasons that can't reliably be predicted or fixed ahead of time, I thin

by a1369209993 5y ago

> The staging tree is for sketchy code. If the code is likely to fail in weird ways for reasons that can't reliably be predicted or fixed ahead of time, I think it's fair to call it sketchy. If the code uses instructions that might be defined out from under it, it's likely to fail in weird ways for reasons that can't reliably be predicted or fixed ahead of time. No claim on whether it's a good idea (the "discourage bad hardware" angle would suggest not), but "staging is for sketchy drivers" at least seems consistent with including it.

kelnos 5y ago
> If the code uses instructions that might be defined out from under it They won't, though, at least not in a way that matters. Linux exists to make hardware run. There is hardware built against the current draft version of the H extension. KVM should be made to work on that hardware. If the final ratified H extension ends up having incompatible changes to what's there now, then that's just another revision that the kernel can support, just like Linux can support different features in different x86 generations. If the hardware manufacturers were being reckless and shipping an earnestly-worked-on pre-standard before it was ready, I would perhaps agree that they shouldn't get mainline support. But it seems the H extension has been sitting in limbo for a year now, and it seems the reason is that a company that is having trouble getting hardware ready for shipping is trying to stall the process so other companies don't have a leg up. That's not a good reason to punish these other (more competent?) companies by forcing them to carry out-of-tree patches. And given the situation, it's likely that the eventually-ratified version will be the same as (or at least compatible with) the current draft, so the risk of taking the code now and having to maintain compatibility hacks later is pretty low.
colonwqbang 5y ago
The hardware that is already designed and built and sold will never change. It will always work the same. It needs to be supported as it exists today. There will be always new HW designed which works differently to the old one. This goes for all types of HW. They never stop.

kelnos 5y ago

> If the code uses instructions that might be defined out from under it They won't, though, at least not in a way that matters. Linux exists to make hardware run. There is hardware built against the current draft version of the H extension. KVM should be made to work on that hardware. If the final ratified H extension ends up having incompatible changes to what's there now, then that's just another revision that the kernel can support, just like Linux can support different features in different x86 generations. If the hardware manufacturers were being reckless and shipping an earnestly-worked-on pre-standard before it was ready, I would perhaps agree that they shouldn't get mainline support. But it seems the H extension has been sitting in limbo for a year now, and it seems the reason is that a company that is having trouble getting hardware ready for shipping is trying to stall the process so other companies don't have a leg up. That's not a good reason to punish these other (more competent?) companies by forcing them to carry out-of-tree patches. And given the situation, it's likely that the eventually-ratified version will be the same as (or at least compatible with) the current draft, so the risk of taking the code now and having to maintain compatibility hacks later is pretty low.

colonwqbang 5y ago

The hardware that is already designed and built and sold will never change. It will always work the same. It needs to be supported as it exists today. There will be always new HW designed which works differently to the old one. This goes for all types of HW. They never stop.