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

[Tim Bird <tim.bird@sonymobile.com>]

On 08/12/2014 09:23 AM, Grant Likely wrote:
> On Tue, Aug 12, 2014 at 5:15 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 08/12/2014 06:00 AM, Grant Likely wrote:
>>>
>>> On Tue, 12 Aug 2014 01:13:07 +0900, Masami Hiramatsu
>>> <masami.hiramatsu.pt@hitachi.com> wrote:
>>>>
>>>> (2014/08/11 23:11), Shuah Khan wrote:
>>>>>>
>>>>>> (2014/08/07 23:36), Shuah Khan wrote:> As a first step towards a larger
>>>>>> goal to enable developer
>>>>>>>
>>>>>>> friendly kernel testing framework, a new make target is
>>>>>>> planned for 3.17. In addition, 3.17 includes work done to
>>>>>>> fix tools/testing/sefltests to run without failures.
>>>>>>>
>>>>>>> Short summary of work done so far for 3.17:
>>>>>>>
>>>>>>> - fix compile errors and warnings in various tests
>>>>>>> - fix run-time errors when tests aren't run as root
>>>>>>> - enhance and improve cpu and memory hot-plug tests
>>>>>>>       to run in limited scope mode by default. A new make
>>>>>>>       target to select full-scope testing. Prior to this
>>>>>>>       change, cpu and memory hot-plug tests hung trying to
>>>>>>>       hot-plug all but cpu0 and a large portion of the memory.
>>>>>>> - add a new kselftest target to run existing selftests
>>>>>>>       to start with.
>>>>>>
>>>>>>
>>>>>> Instead of running the selftests, can we build the testcases and
>>>>>> install it as a tool? I think running tests on the tree is not a
>>>>>> good idea...
>>>>>
>>>>>
>>>>> One of the goals is to leverage developer tests that we already have.
>>>>> When a developer makes a kernel change and wants to see if that change
>>>>> lead to any regression, having the ability to buidl and run selftests on
>>>>> the newly installed kernel withe the same source tree is very useful.
>>>>> That is the reason behind adding this new target.
>>>>
>>>>
>>>> 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.
>>>
>>
>> Do you have that public yet ? I might want to use that for my -stable sanity
>> tests.
>
> Nothing yet. It's currently hacked into my build environment script.
> I'm working on getting it into a form usable by others. Ideally I
> think it should go into the kernel tools/testing directory.

I've been doing the same thing, focused on using Aboriginal.  I have
some scripts that I've used for years for abstracting the 
build/boot/test cycle for cross-platform hardware, that I can share. 
But my qemu foo is not so good.

I thought my scripts might overlap with the ktest stuff Steve Rostedt is
doing, and wanted to chat with him at the summit about what parts might
make sense in the kernel tree, and how I might integrate my higher-level
scripts to work with ktest.pl.

As for tests, one of the ones I'd really like to see in mainline is a 
basic size test.  I have one based on my scripts I can dust off.  It 
generates the "size" for all config options by doing on vs. off 
build/boot/size comparisons for each config option.

  -- Tim