Of course they should. Linux needs to work on hardware that exists not just on hardware that may, one day, exist.
> Don't further pollute the kernel.
One of the primary jobs of kernels, drivers and compilers is to abstract some of the underlying hardware complexity away. Kernels, drivers and compilers have always dealt with bugs and limitations in hardware.
Things like retpoline and CPU barriers aren't especially unusual. Emergency fixing such a pervasive issue is unusual though, hence the attention.
> ubiquity is not an excuse
No, but it's a really, really good reason
If I were inclined to facetiousness (which I'm not), I would point out that there is a large number of other kernels out there that aren't especially performant and don't work well on most hardware. If you really object to this, you can always use one of those.
Of course they should. Linux needs to work on hardware that exists not just on hardware that may, one day, exist.
> Don't further pollute the kernel.
One of the primary jobs of kernels, drivers and compilers is to abstract some of the underlying hardware complexity away. Kernels, drivers and compilers have always dealt with bugs and limitations in hardware.
Things like retpoline and CPU barriers aren't especially unusual. Emergency fixing such a pervasive issue is unusual though, hence the attention.
> ubiquity is not an excuse
No, but it's a really, really good reason
If I were inclined to facetiousness (which I'm not), I would point out that there is a large number of other kernels out there that aren't especially performant and don't work well on most hardware. If you really object to this, you can always use one of those.