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

[Guenter Roeck]

On 08/13/2014 09:44 AM, Bird, Tim wrote:
> 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.
>

You would also need working configurations. There may be a few exceptions,
where one of the defconfigs can be used as is, but in most cases at least
some minor tweaks are needed to create a kernel that is working with qemu.
Or at least that is my experience.

Guenter