On 5/9/19 3:20 PM, Logan Gunthorpe wrote:
On 2019-05-09 3:42 p.m., 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
>> real hardware or in a virtual machine. That seems to be a matter of
>> to me because isn't invoking a UML Linux just running the Linux kernel
>> 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.
I'm back to reply to this subthread, after a delay, as promised.
I largely agree with everything Ted has said in this thread, but I
wonder if we are conflating two different ideas that is causing an
impasse. From what I see, Kunit actually provides two different
1) An execution environment that can be run very quickly in
on tests in the kernel source. This speeds up the tests and gives a
lot of benefit to developers using those tests because they can get
feedback on their code changes a *lot* quicker.
kselftest in-kernel tests provide exactly the same when the tests are
configured as "built-in" code instead of as modules.
2) A framework to write unit tests that provides a lot of the same
facilities as other common unit testing frameworks from userspace
(ie. a runner that runs a list of tests and a bunch of helpers such
as KUNIT_EXPECT_* to simplify test passes and failures).
The first item from Kunit is novel and I see absolutely no overlap
with anything kselftest does. It's also the valuable thing I'd like
to see merged and grow.
The first item exists in kselftest.
The second item, arguably, does have significant overlap with
kselftest. Whether you are running short tests in a light weight UML
environment or higher level tests in an heavier VM the two could be
using the same framework for writing or defining in-kernel tests. It
*may* also be valuable for some people to be able to run all the UML
tests in the heavy VM environment along side other higher level
Looking at the selftests tree in the repo, we already have similar
items to what Kunit is adding as I described in point (2) above.
kselftest_harness.h contains macros like EXPECT_* and ASSERT_* with
very similar intentions to the new KUNIT_EXECPT_* and KUNIT_ASSERT_*
I might be wrong here because I have not dug deeply enough into the
code!!! Does this framework apply to the userspace tests, the
in-kernel tests, or both? My "not having dug enough GUESS" is that
these are for the user space tests (although if so, they could be
extended for in-kernel use also).
So I think this one maybe does not have an overlap between KUnit
However, the number of users of this harness appears to be quite
small. Most of the code in the selftests tree seems to be a random
mismash of scripts and userspace code so it's not hard to see it as
something completely different from the new Kunit:
$ git grep --files-with-matches kselftest_harness.h *
Thus, I can personally see a lot of value in integrating the kunit
test framework with this kselftest harness. There's only a small
number of users of the kselftest harness today, so one way or another
it seems like getting this integrated early would be a good idea.
Letting Kunit and Kselftests progress independently for a few years
will only make this worse and may become something we end up
Yes, this I agree with.