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

Shuah Khan shuah.kh at samsung.com
Tue Aug 12 16:34:40 UTC 2014


On 08/12/2014 07:00 AM, Grant Likely wrote:
> On Tue, 12 Aug 2014 01:13:07 +0900, Masami Hiramatsu <masami.hiramatsu.pt at 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 haven't given this too much thought yet. It is at the back on
my mind. A couple of issues that will need to be worked to get
kselftest working in cross-build env.:

- tests (Makefiles especially) probably need work to pick the right
   compiler and so on. This would be first step.
- some tests probably aren't suited for all cross env. The goal
   should be though to keep this set to minimum.

>
> 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.
>

Great. Why not? The first step would be get kselftest compiling in
cross-builds. I haven't tried it yet, however in a private
response to this thread, one developer mentioned that some tests
don't pick the correct compiler result of hard-coded gcc instead
of using $(CC) and assumptions on libraries. So as we go forward
we have to get these things fixed along the way.

-- Shuah



-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh at samsung.com | (970) 672-0658


More information about the Ksummit-discuss mailing list