lkml.org 
[lkml]   [2015]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)
From
On Sun, Jan 4, 2015 at 12:45 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> Because we're discussing a choice between two evils.

.. and Pavel pointed you to several screenfuls of google hits for
people complaining about this.

End of discussion. Seriously. Your whinging about "support costs" is
just crying over the fact that you have users. Deal with it.

I've reverted the change for now, since that's clearly better than
leaving things broken. And you should acknowledge that. In fact, you
should *more* than acknowledge that, you need to internalize it and
*understand* it, instead of arguing.

The fact is, we have bogomips on x86 too, and they've been around for
a hell of a lot longer than ARM has been. The number may not be
"meaningful" any more (since it's TSC cycles rather than anything
else), but it's there in /proc anyway. We had it through the times
when it fluctuated, and your made-up arguments about how it's a bad
thing are just bogus. It wasn't a big deal, and having a reasonable
value is not a problem.

And no, we don't set it to some "obviously bogus value". That just
makes breakage even more subtle.

You could make it be something that is roughly on the order of the CPU
frequency. It doesn't have to be exact, but from a QoI standpoint, try
to do a reasonable job.

And dammit, I really never *ever* want to hear arguments against
fixing regressions ever again. It really is the #1 rule for the
kernel. There is *no* excuse for that NAK. There is only "sorry".

Linus


\
 
 \ /
  Last update: 2015-01-04 22:21    [W:0.091 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site