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: <20100630104043.GG11746@pengutronix.de>
Date:	Wed, 30 Jun 2010 12:40:43 +0200
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	Russell King <rmk@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Eric Miao <eric.miao@...onical.com>,
	linux-omap@...r.kernel.org, Nicolas Pitre <nico@...xnic.net>
Subject: Re: ARM defconfig files

Hi Linus,

I think my mail hit your inbox during your vacation.  As this is quite
important for the ARM people and there isn't much time left, can you
please comment?

Thanks in advance
Uwe

On Mon, Jun 14, 2010 at 10:32:14AM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> [Added linux-arm-kernel ML to Cc, note that it's moderated for
> non-subscribers.]
> 
> On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 3 Jun 2010, Daniel Walker wrote:
> > > 
> > > I don't see how we can do without defconfigs altogether tho. I mean , if
> > > you want to run a Beagle board or a Nexus one we can't just give the
> > > users a slim ARM config and let them troll through 1000's of drivers
> > > trying to find just those ones that work on their given board.
> > 
> > Well, you also don't need the full defconfig's with the kernel.
> > 
> > Right now they are just noise. They actually _hide_ things, because 
> > diffstat (and dirstat) information becomes pointless, and the diffs become 
> > totally unreadable by any human (trust me - when the choice is between 
> > "search for next relevant diff" or "blast it, I can't be bothered with 
> > walking through this crap", quite often the choice is the latter).
> I wrote a script that throws out all unneeded lines in all arm
> defconfigs that don't influence the resulting .config for .34 and
> .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced.
> 
> Here are the results:
> 
> 	$ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm
> 	  11.8% arch/arm/configs/
> 	  10.0% arch/arm/mach-msm/
> 	  10.8% arch/arm/mach-omap2/
> 	   4.8% arch/arm/mach-pxa/
> 	   4.5% arch/arm/mach-s5pc100/
> 	   3.3% arch/arm/mach-s5pv210/
> 	   4.4% arch/arm/mach-spear3xx/
> 	   3.1% arch/arm/mach-ux500/
> 	   5.1% arch/arm/plat-s5pc1xx/
> 	   3.1% arch/arm/plat-samsung/
> 	  38.2% arch/arm/
> 
> 	$ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm
> 	   3.1% arch/arm/mach-davinci/
> 	  11.3% arch/arm/mach-msm/
> 	  12.2% arch/arm/mach-omap2/
> 	   5.4% arch/arm/mach-pxa/
> 	   5.1% arch/arm/mach-s5pc100/
> 	   3.7% arch/arm/mach-s5pv210/
> 	   5.0% arch/arm/mach-spear3xx/
> 	   3.5% arch/arm/mach-ux500/
> 	   5.8% arch/arm/plat-s5pc1xx/
> 	   3.5% arch/arm/plat-samsung/
> 	  40.9% arch/arm/
> 
> 	$ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config
> 	   1.1% arch/arm/configs/
> 
> 	$ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1
> 	 177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> (The insertions above are only moved lines I think, I didn't check them
> all.)
> 
> The branches arm/defconfig/reduced-v2.6.34 and
> arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at
> git://git.pengutronix.de/git/ukl/linux-2.6.git .  (There is a gitweb at
> http://git.pengutronix.de/?p=ukl/linux-2.6.git)
> 
> So maintaining these minimal defconfigs would have reduced the defconfig
> noise from 11.8% down to 1.1%.  And probably it could be considerably
> reduced further with constructs like:
> 
> 	config HAVE_MTD_NAND_MXC
> 		bool
> 
> 	config MTD_NAND_MXC
> 		tristate "MXC NAND support"
> 		...
> 		default m if HAVE_MTD_NAND_MXC
> 		help
> 		  ...
> 
> 	...
> 	config MACH_MX27ADS
> 		...
> 		select HAVE_MTD_NAND_MXC
> 
> .  Compared with selecting everything in Kconfig files this approach
> allows further tweaking of a config.  (E.g. "I have a mx27ads machine,
> but I don't need nand support.")  Compared with the SAT-Solver it's an
> idea that works today.
> 
> One downside of this approach (when done with my script only) is that
> too much is removed.  E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed.
> This is OK from a logical POV but then changing the default of the
> corresponding choice (and I intend to do that in the near future) would
> break this defconfig.
> 
> I can share my script and I'm willing to support maintaining the
> minimality of the defconfig files if they are an acceptable (maybe
> intermediate) step for Linus.
> 
> Together with the efforts to reduce the number of defconfigs as thought
> about in other mails of this thread the situation should become quite
> better for Linus.  (I'm currently working on merging support for all
> Freescale SoCs into a single mach- directory and so merge mx1_defconfig,
> mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and
> mx51_defconfig.)
> 
> Linus: I would really appreciate if you wouldn't remove all (or nearly
> all) defconfig files.  I think you would force a quicker solution to
> this problem, but during that time the ARM community would loose compile
> coverage.
> 
> Thoughts on this?
> 
> Best regards
> Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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