lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 15 May 2013 13:47:37 +0200
From:	Pavel Machek <pavel@....cz>
To:	Will Deacon <will.deacon@....com>
Cc:	Nicolas Pitre <nico@...xnic.net>,
	Rob Herring <robherring2@...il.com>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/2] ARM: delay: print dummy values for bogomips

On Wed 2013-05-15 10:01:03, Will Deacon wrote:
> Hi Nico,
> 
> On Wed, May 15, 2013 at 12:56:51AM +0100, Nicolas Pitre wrote:
> > On Tue, 14 May 2013, Rob Herring wrote:
> > > On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre <nico@...xnic.net> wrote:
> > > > Waitaminute... Didn't you just claim this would be an ABI break?
> > > >
> > > > So if no application can be found, where is the ABI breakage?
> > > 
> > > lscpu
> > > 
> > > But that is already "broken" on ARM because x86 uses "bogomips" and
> > > ARM uses "BogoMIPS". 
> > 
> > So basically it won't be any more broken if the field disappears 
> > entirely, right?
> 
> It's not these sort of tools I was worried about. I was thinking about the
> possibility of badly written parsers which want some other field from
> cpuinfo, but use the bogomips line for context. Do these applications exist?
> No idea.

Yes, they do. bogomips is not nearly as bogus as you imply.

See

http://www.clifton.nl/index.html?bogomips.html

https://play.google.com/store/apps/details?id=com.securiteinfo.android.bogomips&hl=en

> My second (less stupid) version of the patch prints "not reported". I'd be
> happy to remove the line altogether if people get behind the decision though.
> In fact, I just tried it and at least my linaro filesystem seems happy
> enough.

Would it be too much work to simply put the field back with the right
value? We don't have to get it as precise as we used to, that should
make slowdown minimum.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ