On Sun, 4 Jan 2015, Linus Torvalds wrote: > On Sun, Jan 4, 2015 at 12:03 PM, Nicolas Pitre <nicolas.pi...@linaro.org> > wrote: > > > > NAK. > > To quote the standard response for people who ignore regressions: > > "SHUT THE FUCK UP" > > you cannot NAK regression fixes. Seriously. > > I don't understand how people can't get this simple thing.
OK, let's look at the issue more deeply then. We're talking about exporting a bogomips entry via /proc/cpuinfo. On ARM the calibration loop is no longer performed because udelay() is based on a hardware counter these days. Why? because the calibration was completely unreliable in the presence of CPU frequency scaling, and other modern hardware niceties. Still, for a while, we did export the calibration loop value for /proc/cpuinfo's sake. Yet people complained because the exported value was "wrong". Of course it is wrong as it is just impossible to get "right", unless you have antique hardware that is. > No regressions. If user mode breaks, it is absolutely *never* > acceptable to blame user mode. > > Occasionally there may be major overriding reasons (security issue, > whatever), but even then we bend over *backwards* trying to make sure > breakage is minimal. I'm all for ensuring breakage is minimal. That'd imply settling on a good phony bogomips value that is no more broken than the real one was when it was exported. > Christ people. Why does this even have to be discussed any more? Because we're discussing a choice between two evils. The actual regression happened when people upgraded their antique hardware and expected the bogomips to still work with new hardware. Even if the $subject commit is reverted, that won't solve the wrong bogomips problem and different people will start complaining again. As I mentioned earlier, putting the entry back is not a problem if we may find the best phony number to go along with it. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
