4 ms·

That's not how it works. The Linux kernel is chock full of drivers for sketchy hardware. The staging tree is for sketchy code. If the feature is in shipping har

That's not how it works. The Linux kernel is chock full of drivers for sketchy hardware. The staging tree is for sketchy code. If the feature is in shipping hardware and useful, Linux policy is to support it.

Ericson2314 5y ago
That's a fair distinction. I still like Linux "helping out" RISC-V standardization by separating the unratified extensions --- traditionally the hardware is fait accompli and Linux is the agile software playing catch up but with something like RISC-V the roles are somewhat reversed --- but I fully grant that's separate to the purpose of staging as you say.
- marcan_42 5y ago
  This isn't just a RISC-V thing. There is significant bureaucracy in Linux to push back on vendors doing even dumber stuff with hardware in the future; that was a lot of the discussion around my patches to support the M1. We have to support the hardware, but do so in a way that does not encourage vendors to push things further (we know Apple doesn't care about any of this, but e.g. nobody wants Qualcomm or Broadcom, who do build platforms that intend to run Linux as a first-class citizen, to get any silly ideas). But this is all stuff you work out by looking at the finer points of the implementation and doing it in a way that does not encourage further divergence; certainly throwing stuff in staging isn't how you do it. Ultimately, Linux's goal is to support the hardware; that support may be done in such a way to discourage future "bad" hardware, but it still has to be there as proper support, if the features have merit. For example, we have a patch series in review right now to support KVM on the M1, because (surprise surprise) Apple did some nonstandard stuff there too. It's definitely not going in staging though :) On the other hand, it's less likely that mainline Linux will quickly gain support for, say, things like Apple's proprietary security features (their pointer auth extensions, paging protection stuff, etc) unless there are similar mechanisms implemented in other vendors' CPUs, because those things provide only marginal benefit for end users of specific systems, and Linux has bigger security fish to fry first.
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.

Ericson2314 5y ago

That's a fair distinction. I still like Linux "helping out" RISC-V standardization by separating the unratified extensions --- traditionally the hardware is fait accompli and Linux is the agile software playing catch up but with something like RISC-V the roles are somewhat reversed --- but I fully grant that's separate to the purpose of staging as you say.

marcan_42 5y ago
This isn't just a RISC-V thing. There is significant bureaucracy in Linux to push back on vendors doing even dumber stuff with hardware in the future; that was a lot of the discussion around my patches to support the M1. We have to support the hardware, but do so in a way that does not encourage vendors to push things further (we know Apple doesn't care about any of this, but e.g. nobody wants Qualcomm or Broadcom, who do build platforms that intend to run Linux as a first-class citizen, to get any silly ideas). But this is all stuff you work out by looking at the finer points of the implementation and doing it in a way that does not encourage further divergence; certainly throwing stuff in staging isn't how you do it. Ultimately, Linux's goal is to support the hardware; that support may be done in such a way to discourage future "bad" hardware, but it still has to be there as proper support, if the features have merit. For example, we have a patch series in review right now to support KVM on the M1, because (surprise surprise) Apple did some nonstandard stuff there too. It's definitely not going in staging though :) On the other hand, it's less likely that mainline Linux will quickly gain support for, say, things like Apple's proprietary security features (their pointer auth extensions, paging protection stuff, etc) unless there are similar mechanisms implemented in other vendors' CPUs, because those things provide only marginal benefit for end users of specific systems, and Linux has bigger security fish to fry first.

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.