On Sun, Dec 12, 2010 at 7:43 PM, Grant Likely <grant.lik...@secretlab.ca> wrote:
> Hi all,
Hi Grant. For some reason your email didn't arrive to my redhat
mailbox, go figure...
> 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).
Yes, cross compiling is something very valuable for folks working on
embedded platforms, we definitely need to put support for it in shape.
> 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.
Indeed, but it is secure, considering that you can't always count on a
beefy/available x86 client that can build the kernel for you, which
brings me to the next comment (see below)
> 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.
> - 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.
This is a good idea, but what if you don't have such a client and you
have to rely on your server? And assuming that the client does exist,
will the resulting kernel be transferred to the server, and only then
copying the kernel built to the client? It seems that the logical
order in such cases is:
1) Verify whether there is an available 'build node' client, if not,
fall back to the server as the 'build node'.
2) Build the kernel using an appropriate config
3) Package it, be it a tarball, deb ou rpm pkg
4) Copy to embedded client (test system) and install it
> 3) same as #2, but instead using a wrapper class around the kernel
> class. Or maybe inheriting from the kernel class.
Wrapping the above procedure as a 'cross compiling' kernel class is
indeed a nice idea. It would be an abstraction and the user would have
to worry little other than defining a build node (or leaving the
default to build in the autotest server).
> 4) Some other way I haven't though of?
>
> What is the best way to proceed here?
That is my initial idea about the subject. It'll probably take some
iterations to find an optimal path, so my take, as expressed above, is
to implement 2) (implementing 3 might be a next step).
> 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?
As pointed out by Eric, the API scope of a server control file
provides all the logic necessary to implement such a schema. The
control file to get the build working on different clients would be
slightly different, though. Please bear with me as I just started to
sketch some code to illustrate my point, this is by no means a
finished and tested server control file:
build_node_hostname = 'hostname.node.build'
test_node_hostname = 'hostname.node.test'
build_node = hosts.create_host(build_node_hostname)
build_node_at = autotest.Autotest(build_node)
test_node = hosts.create_host(test_node_hostname)
test_node_at = autotest.Autotest(test_node)
def install_kernel_test_node():
produced_kernel_pkg = '/some/place/in/server'
test_node.send_file(produced_kernel_pkg)
test_node_at.run_test('kernel_install') # need to see the optimal way of
# doing this part
if buld_node_at.run_test('kernel_cross_compile'): # this implies a kernel pkg
install_kernel_test_node() # will be produced and copied
else: # to server
raise error.JobError('Failed to cross compile kernel in test node')
The idea here is that in the server control file scope, each machine
can be instantiated and controlled separately in the python code.
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Autotest mailing list
> Autotest@test.kernel.org
> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
--
Lucas
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
