[Ksummit-discuss] kselftest - What's in 3.17 and plans for 3.18 and beyond

[Bird, Tim]

On Wednesday, August 13, 2014 9:16 AM,Andy Lutomirski wrote:
> 
> On Wed, Aug 13, 2014 at 9:11 AM, Guenter Roeck <linux at roeck-us.net> wrote:
> > On 08/13/2014 01:35 AM, Linus Walleij wrote:
> >>
> >> On Tue, Aug 12, 2014 at 3:00 PM, Grant Likely wrote:
> >>> I'm interested in this as well. I'm working on a tool that crossbuilds a
> >>> very simple busybox rootfs and boots in QEMU for as many architectures
> >>> as possible. I want to make it easy to sanity test all the major
> >>> architectures. Right now it does little more than boot to a login
> >>> prompt, but I'd like to get the kselftests into it also.
> >>
> >>
> >> Hm that sounds like a goal similar to what Rob Landley has
> >> described as one goal for Aboriginal Linux as well.
> >> http://landley.net/aboriginal/about.html
> >>
> >
> > Yes, and to some degree buildroot.
> >
> > Rob's attempts to support multiple architectures also shows its limitations.
> > For example, his m68k images don't work, at least not for me, because the
> > machine he uses (q800) is not supported in qemu 1.6 or 2.0 or 2.1.
> > I have been unable to find a working combination of kernel configuration,
> > qemu version, qemu command line, and root file system for m68k. Presumably
> > that must exist, because qemu supports m68k, I just have not been able
> > to figure out how to make it work.
> >
> > For my own qemu runtime tests, I ended up collecting root file systems and
> > kernel configurations from all over the place. And then there is the problem
> > of qemu command line parameters, where each target and architecture requires
> > its own set of options, and it is sometimes all but impossible to find a
> > working set of parameters for a given target/architecture combination.
> >
> 
> virtme has exactly this problem (except for the root image part --
> virtme can use debootstrap output directly).  In virtme, I'm trying to
> solve it by just collecting known-working QEMU arguments and
> documenting the corresponding kernel config requirements.

I'm wondering if the kernel test tree might be a good place to keep such 
virtual machine/QEMU configurations.  They should be only about 1 line
(or a few lines)  per machine, and they would be useful for automated testing.
I also think they won't change every kernel release, so it shouldn't lead to the churn
problem we had with defconfigs.

Would there be objections to hosting this information in 
the kernel source tree?
 -- Tim