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

[Andy Lutomirski <luto@amacapital.net>]

On Wed, Aug 13, 2014 at 9:11 AM, Guenter Roeck <linux@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 <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.
>

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.

--Andy