Date:	Thu, 07 Mar 2013 16:47:38 -0600
From:	Rob Landley <rob@...dley.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Mike Frysinger <vapier@...too.org>,
	Ingo Molnar <mingo@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Russell King <linux@....linux.org.uk>,
	Michal Simek <monstr@...str.eu>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Richard Weinberger <richard@....at>
Subject: Re: [PATCH v2] early_printk: consolidate random copies of identical
 code

On 03/07/2013 03:35:42 PM, Andrew Morton wrote:
> On Thu, 7 Mar 2013 14:50:23 -0500 Paul Gortmaker  
> <paul.gortmaker@...driver.com> wrote:
> 
> > This brings up a recurring question.  I was tempted to just go make
> > CONFIG_EARLY_PRINTK depend on CONFIG_PRINTK, but lately I've faced
> > pushback when trying to "fix" things like seeing ARM OMAP USB  
> options
> > for an x86 build[1], and GOLDFISH virt drivers being offered even
> > when the end user already said no to GOLDFISH[2].
> >
> > Do we want to use dependencies to reflect the real world layout of
> > platforms/systems, or do we want to go the minimal dependency
> > approach, where we are building sparc specific drivers on mips just
> > because we can?
> >
> > I think the former is better from a user specific point of view, as
> > the maze of Kconfig is better as a tree topology with branches that
> > have clear dependencies that exclude them, versus it being a flat
> > monolithic space where anything can select anything.
> >
> > Arguments I've heard for the latter seem to be developer centric
> > (i.e forcing wider build coverage on the population as a whole, etc)
> 
> For me personally, I really really want good compilation coverage.  It
> drives me bats when I merge a patch but have to jump through a series
> of hoops (such as not having the appropriate cross-compiler!) to be
> able to build the thing.

This doesn't solve everything, but:

http://landley.net/aboriginal/bin

cross-compiler-*.tar.bz2 is statically linked cross compilers for a lot  
of different architectures. Add the "bin" subdirectory to your path and  
CROSS_COMPILE=prefix- where prefix is whatever the * was (and the  
trailing - is important).

system-image-*.tar.bz2 is bootable system images with native  
development tools (./run-emulator.sh and ./dev-environment.sh are  
wrapper scripts to boot qemu with all the right arguments), for the  
same set of architectures. (There are a couple I have cross compilers  
for but insufficient board support in qemu as of yet. Working on it.  
I'm also working on adding more targets, but it's multitasked with  
several other projects...)

Note that if you have distccd installed on the host and the cross  
compiler is in your $PATH, ./dev-environment.sh should hook up distcc  
to the cross compiler through qemu's emulated network.

So at least _build_ coverage and basic "it booted to a shell prompt"  
smoke test coverage are reasonably straightforward. (I have automated  
build control images that build linux from scratch under the result,  
hence wanting distcc to make it slightly less slow.)

Driver testing for strange hardware continues to require strange  
hardware, though.

(If you're curious, http://landley.net/aboriginal/about.html goes on  
about it.)

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