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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 06 May 2008 02:21:31 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Alexander Viro <viro@....linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches

Ingo Molnar <mingo@...e.hu> writes:

> But the per patch benefit is arguably extremely low: for example this 
> particular patch saves 0.00016% from my particular vmlinux's size.

I don't think the code changes actually with current gcc for integer
code if you change something from global to static (unless it causes
gcc to inline the function, but then it might be well larger if you're
unlucky)

The only file size change you'll see will be from a smaller symbol
table in the vmlinux ELF file, but that is not even loaded at run time
or included into the bzImage (and the kallsyms table has statics too)

So if we follow that "smaller symbol table" is better model
should we make a rule that all globals be 8 characters only? Or perhaps 6?  @)
I'm sure that could be easily enforced by some tool... 

I could see some advantage from static in future compiler versions 
though from better optimization, but it's quite remote.

I agree with your point that it's not effective to spend human time
to generate such patches.

-Andi
--
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