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:	Thu, 3 Jun 2010 19:46:23 +0300
From:	Tony Lindgren <tony@...mide.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: ARM defconfig files

* Linus Torvalds <torvalds@...ux-foundation.org> [100603 17:48]:
> 
> So I _think_ whatever "mach-xyz" file _should_ do something like
> 
> 	# Kconfig file for OMAP4ABCXYZ chip
> 
> 	.. set the particulars for this _particular_ chip,
> 	   ie select the particular drivers on this chip ..
> 
> 	include "chip-family-details" (ie maybe "base OMAP details")
> 
> 	include "architecture-family-details" (ie ARM Kconfig)
> 
> see? Not one flat file, and very much not something generated.
> 
> And I actually suspect we could do it with our current Kconfig file model. 
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have 
> basically a
> 
> 	choice
> 		prompt "ARM platform"
> 
> 	config ARM_PLATFORM_OMAP
> 		bool PLATFORM_OMAP
> 
> 	config ARM_PLATFORM_MSM
> 		bool PLATFORM_MSM
> 	...
> 	endchoice
> 
> 	if ARK_PLATFORM_OMAP
> 	 include "Kconfig.omap"	# this will further have choices for OMAP versions
> 	elif ARM_PLATFORM_...
> 
> and then the individual "Kconfig.platform" files could select certain 
> options, and then do a "include Kconfig.cpu" which would actually be the 
> _current_ top-level arch/arm/Kconfig.

Some of this work has been already done like I responded in the other
thread. So we could use the current omap3_defconfig for omap2, 3 & 4
with some more work. Then do the same thing for omap1. That would cut
it down by total of 38 defconfigs.

Compiling in multiple ARM platforms is trickier, we would have to get
rid of the duplicate defines like NR_IRQS, then have some common clock
framework etc. Then figure out some way to get rid of Makefile.boot.
Russell probably has some other things in mind that would have to be
changed to make this happen.
 
> And I don't think we can get there from here unless I at some point say "I 
> just removed the xyz_defconfig files", at which point people will curse me 
> and stumble about until they actually come up with something better.
> 
> Of course, if the ARM people do something proactive like the above 
> _before_ I remove the defconfig files, I won't complain.

Whenever you feel like it, please just go ahead and do:

$ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm

That way maybe you can wait a bit longer for the other defconfigs
and as an extra bonus I won't get flamed for removing these omap
defconfigs ;)

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