[Ksummit-2012-discuss] [ATTEND] writeback and kernel testing

Mel Gorman mgorman at suse.de
Wed Jun 20 09:52:43 UTC 2012


On Tue, Jun 19, 2012 at 10:03:19PM +0100, Ralf Baechle wrote:
> On Tue, Jun 19, 2012 at 04:50:30PM -0400, Steven Rostedt wrote:
> 
> > > Actually, this should be doable *without* any special hardware or
> > > setup.  QEMU has models for all the major architectures.  It would be
> > > useful to have a tool in the kernel tree that builds and boots a set
> > > of kernel configs on QEMU, assuming that the user has the relevant
> > > cross compilers installed and that there is are a set of rootfs images
> > > to use for each architecture.
> > > 
> > > If done right, a maintainer (or submitter) can fire off a command to
> > > sanity-test their kernel tree before pushing it out to linux-next.
> > > I've been thinking about this for a while now, but haven't had the
> > > time to hack on it.
> > 
> > Hmm, I should look into setting up qemu binaries (or better yet, someone
> > else do it for me :-) and post them up on kernel.org. Then we could set
> > up ktest to kick off various tests with different kernels and different
> > kernel configs.
> > 
> > That shouldn't be too hard.
> 
> Fedora and probably most other major distributions are shipping qemu
> binaries for a variety of target architectures which are ARM, cris, m68k,
> MIPS (big and little endian, 32-bit and 64-bit), SH4 (big and little
> endian), i386 and x86-64.  So the binaries are not the problem.
> 
> Setting up the necessary root file systems, shell scripts to launch
> qemu instances, run tests in those qemu instances, which kernel
> configuration to use with which qemu config options, target platform
> and architecture specific nastyness and more are the real time wasters.
> 

It's not a complete disaster either. I have a script that runs from a server,
attaches serial console, optionally builds and installs a kernel (but also
handles rpm installation) and downloads results from tests. The main script
is just 414 lines of shell script. It depends on some other scripts but they
are not massive either. This is for tests running on bare metal. There is a
certain amount of hard-coding of paths simply because it was not necessary
to be that flexible at the time and it was already dull enough a job.

Image management is a bit annoying all right. All the machines have a fixed
configuration and have a "host" and "guest" partition. To deploy an image
the host is booted, a tar file is copied with dd to the raw partition and
then some fixups applied before booting to it. It's not perfect and it's
not fancy but it's not impossible either. It took a while to setup but
once it's in place, it's trivial to maintain.

> I know of many developers using qemu for testing but I think nobody has
> come up with a decent, userfriendly infrastructure for testing or
> possibly even doing things such as an automated cross-architecture
> bisect.
> 

User-friendly is in the eye of the beholder :)

-- 
Mel Gorman
SUSE Labs


More information about the Ksummit-2012-discuss mailing list