On Mon, Dec 13, 2010 at 10:39:18AM -0800, Eric Li(李咏竹) wrote:
> 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?
Hi Eric,
Yup, I've actually got this working now which is perfect for my use
case. I hope to post patches soon.
> > - 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()
Not quite what I'm looking for. The kernel build job and the boot job
have to run on different clients, so the first job needs to create a
job that will run on a different client. I'm going to try calling the
cli from within the server control file.
Thanks for you help.
g.
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
