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]
Message-Id: <1202545817.6722.24.camel@odie.local>
Date:	Sat, 09 Feb 2008 09:30:17 +0100
From:	Simon Holm Thøgersen <odie@...aau.dk>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Michael Opdenacker <michael-lists@...e-electrons.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Linux-tiny@...enic.com
Subject: Re: [PATCH] x86 (Linux Tiny): configure out support for some
	processors


fre, 08 02 2008 kl. 17:20 -0600, skrev Matt Mackall:
> On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
> > This patch against x86/mm tries to revive an original patch
> > from Matt Mackall which didn't get merged at that time. It makes
> > it possible to disable support code for some processors. This can
> > be useful to support only the exact processor type used
> > in a given system.
> > 
> > I may have made wrong assumptions with the code handling
> > force_mwait. As force_mwait is only declared in
> > arch/x86/kernel/cpu/amd.c, which is only compiled
> > when CONFIG_X86_32 is set, I thought it was safe
> > to make the code depend on CONFIG_CPU_SUP_AMD,
> > but I could be wrong.
> > 
> > Your comments are more than welcome! To make the code
> > cleaner, I could use empty inline functions instead
> > of ifdef's, as suggested in Documentation/SubmittingPatches.
> 
> Please include the output of size with all these options on and off.

The build of my currently running kernel for my laptop has
$ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o
   text	   data	    bss	    dec	    hex	filename
   2809	    316	      0	   3125	    c35	amd.o
   2387	    856	      0	   3243	    cab	cyrix.o
   1514	    312	      0	   1826	    722	centaur.o
   1279	    312	      0	   1591	    637	transmeta.o
   1783	    316	      0	   2099	    833	intel.o
    126	    312	      0	    438	    1b6	nexgen.o
     41	    312	      0	    353	    161	umc.o
   9939	   2736	      0	  12675	   3183	(TOTALS)

That is without optimize for size compilation, with that set I get
$ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o
   text	   data	    bss	    dec	    hex	filename
   2300	    316	      0	   2616	    a38	amd.o
   2132	    820	      0	   2952	    b88	cyrix.o
   1325	    312	      0	   1637	    665	centaur.o
   1151	    312	      0	   1463	    5b7	transmeta.o
   1575	    316	      0	   1891	    763	intel.o
    107	    312	      0	    419	    1a3	nexgen.o
     41	    312	      0	    353	    161	umc.o
   8631	   2700	      0	  11331	   2c43	(TOTALS)

I don't think the code changes in the patch do much with respect to
size.


Simon Holm Thøgersen

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