lkml.org 
[lkml]   [2019]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
From
Date
On 5/9/19 2:42 PM, Theodore Ts'o wrote:
> On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote:
>>
>> "My understanding is that the intent of KUnit is to avoid booting a kernel on
>> real hardware or in a virtual machine. That seems to be a matter of semantics
>> to me because isn't invoking a UML Linux just running the Linux kernel in
>> a different form of virtualization?
>>
>> So I do not understand why KUnit is an improvement over kselftest.
>>
>> ...
>>
>> What am I missing?"
>
> One major difference: kselftest requires a userspace environment; it
> starts systemd, requires a root file system from which you can load
> modules, etc. Kunit doesn't require a root file system; doesn't
> require that you start systemd; doesn't allow you to run arbitrary
> perl, python, bash, etc. scripts. As such, it's much lighter weight
> than kselftest, and will have much less overhead before you can start
> running tests. So it's not really the same kind of virtualization.
>
> Does this help?
>
> - Ted
>

I'm back to reply to this subthread, after a delay, as promised.

That is the type of information that I was looking for, so
thank you for the reply.

However, the reply is incorrect. Kselftest in-kernel tests (which
is the context here) can be configured as built in instead of as
a module, and built in a UML kernel. The UML kernel can boot,
running the in-kernel tests before UML attempts to invoke the
init process.

No userspace environment needed. So exactly the same overhead
as KUnit when invoked in that manner.

\
 
 \ /
  Last update: 2019-05-10 23:13    [W:0.174 / U:45.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site