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

[Guenter Roeck <linux@roeck-us.net>]

On 08/13/2014 01:35 AM, Linus Walleij wrote:
> On Tue, Aug 12, 2014 at 3:00 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Tue, 12 Aug 2014 01:13:07 +0900, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>
>>> I see, for that purpose, installing testcase may not fit.
>>> BTW, how would it cover cross-build?
>>
>> 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.

Guenter