Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)

[Catalin Marinas <catalin.marinas@arm.com>]

On Thu, Jan 08, 2015 at 03:44:53PM +0000, Vince Weaver wrote:
> On Thu, 8 Jan 2015, Russell King - ARM Linux wrote:
> 
> > It's not a regression - yet.  No one has shown that userspace has broken
> > according to the definition of the first quote above, and that's the
> > whole point.
> 
> How much does one have to regress before it is a problem?  I have two 
> projects I've worked on that "broke" due to this issue.  

With the revert in place, now you get the bogomips value. Just don't
assume anything about it.

> They were minor breakages though.
> 
> The "linux_logo" userspace sysinfo tool broke to the extent that it 
> was parsing for the bogomips string in /proc/cpuinfo and printed poorly 
> formatted and/or corrupted text info to screen when it couldn't find it.

We now have the bogomips string back, so this problem is solved.

> The "PAPI" library had some really ancient (and poorly 
> thought-out) fallback code that would try to estimate MHz from bogomips 
> if a MHz value was not available via the traditional methods.  This
> failed after the change too, but not many people use PAPI on ARM so it 
> wasn't that big an issue.
> 
> I noticed these problems early, even before the change hit mainline.
> But when I complained I was told in no uncertain terms that the ARM
> maintainers were tired of hearing about bogomips issues and nothing
> could be done to stop the change from getting in.

There were many complaints, from marketing people to some Linux users
who had a "feeling" that their platform just got much slower after the
delay loop change. Since this patch didn't gain much traction:

https://lkml.org/lkml/2013/5/3/405

we decided to remove it completely so that we stop complaints that
bogomips does not match the CPU frequency. Unfortunately, we broke the
ABI.

Now the bogomips is back, but we are going to ignore anyone asking about
its value as it can be either the speed of a busy delay loop or the
generic timer frequency (completely independent; which one depends on
kernel version and SoC).

I really think we should stop this thread. User ABI breakage fixed now.

-- 
Catalin