some light thought inline.
On Sun, Dec 12, 2010 at 1:43 PM, Grant Likely <grant.lik...@secretlab.ca>wrote:
> Hi all,
>
> I'm in the process of bringing up Autotest to control my board farm
> which covers a number of different architectures (ARM, PowerPC,
> Microblaze & Sparc to name a few). I'm setting it up so that I can
> automate sanity testing of my kernel branches before pushing them out
> to linux-next. My goal is to have a setup that will:
>
> - submit a git commit id to be tested (ideally via the cli interface)
> - checkout the kernel tree on a build machine (x86 or PowerPC)
> - cross-compile kernel for N architectures/platforms (ARM, PowerPC,
> MIPS, x86, Sparc, etc)
> - Boot each resulting kernel on one or more QEMU instance and/or real
> hardware
> - report the results (of course).
>
> So far, I've got conmux and autoserv set up and it seems to work
> really well for running tests on my target boards. Now I'm trying to
> add in the kernel build, and I need some advice/recommendations.
>
> From what I can tell, server/git_kernel.py implements the
> functionality for building a kernel for a git tree, but it does so by
> copying the kernel source to the client and building it natively.
> There doesn't seem to be any support for cross compiling the kernel.
> This doesn't really match my use case because most of the clients are
> cut down embedded systems which many not have a native compiler
> installed, and besides it is much faster to cross compile the kernel
> on one of my x86/powerpc servers. client/bin/kernel.py seems to have
> some cross-compile support (even though the comments say it is
> broken), but I don't see any support for fetching a kernel from a git
> tree.
>
> From here I see a few options:
> 1) Modify server/git_kernel.py to support cross compiling and use an
> autoserv control file to send the source to an x86 build client (quite
> possibly the local machine) to cross compile it.
> - This seems sub-optimal since it means there are two copies of the
> kernel source tree; one on the autoserv machine, and one pushed out to
> the build client.
> 2) Modify client/bin/kernel.py to support fetching the source from a
> git tree and running it as a client test with one of my x86 servers as
> the client.
> - This seems to fit more naturally into the autotest design since
> building the kernel is a test in itself, but it looks like I need to
> do some work to create a kernel crosscomple test and to make the
> resulting kernel available to autoserv tests.
>
Create a kernel crosscompile test should not be so hard, and I guess you
could fetch back resulting kernel if you put it under result log directory?
> - There is probably some code in server/git_kernel.py that can be
> factored out and used for both client-side and server-side kernel
> build activities.
> 3) same as #2, but instead using a wrapper class around the kernel
> class. Or maybe inheriting from the kernel class.
> 4) Some other way I haven't though of?
>
> What is the best way to proceed here?
>
> Also, I need to figure out how to make the boot tests depend on the
> kernel building correctly. ie. only boot the powerpc target boards
> if/when the powerpc kernel build test completes correctly. How do I
> do this? Should I be calling the CLI from the kernel build test
> script when the build completes? Is there a better way to schedule
> dependent tests?
>
> This could be done by a server side control file? server control file can
reboot a client target easily,
something like:
client = hosts.create_host(machine)
</gitweb/?p=autotest.git;a=blob;f=server/site_tests/suites/control.regression;h=e023b6048a52e3fb7ab43313fe3fac30954cc215;hb=HEAD#l107>
client_at = autotest.Autotest(client)
if client_at.run_job('client_crosscompiling_test', args='powerpc'):
client.reboot()
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Eric Li
李咏竹
Google Kirkland
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
