Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
From: shuah
Date: Fri Oct 04 2019 - 20:49:50 EST
On 10/4/19 6:33 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 4:57 PM shuah <shuah@xxxxxxxxxx> wrote:
On 10/4/19 5:52 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
However, if I encourage arbitrary tests/improvements into my KUnit
branch, it further diverges away from torvalds/master, and is more
likely that there will be a merge conflict or issue that is not related
to the core KUnit changes that will cause the whole thing to be
rejected again in v5.5.
The idea is that the new development will happen based on kunit in
linux-kselftest next. It will work just fine. As we accepts patches,
they will go on top of kunit that is in linux-next now.
I don't see how this would work. If I add unit tests to ext4, they
would be in fs/ext4. And to the extent that I need to add test mocks
to allow the unit tests to work, they will involve changes to existing
files in fs/ext4. I can't put them in the ext4.git tree without
pulling in the kunit changes into the ext4 git tree. And if they ext4
unit tests land in the kunit tree, it would be a receipe for large
numbers of merge conflicts.
That's where I was originally coming from.
So here's a dumb idea: what if we merged KUnit through the ext4 tree?
I imagine that could potentially get very confusing when we go back to
sending changes in through the kselftest tree, but at least it means
that ext4 can use it in the meantime, which means that it at least
gets to be useful to one group of people. Also, since Ted seems pretty
keen on using this, I imagine it is much more likely to produce real
world, immediately useful tests not written by me (I'm not being lazy,
I just think it is better to get other people's experiences other than
my own).
That doesn't make sense does it? The tests might not be limited to
fs/ext4. We might have other sub-systems that add tests.
Well, I have some small isolated examples that I think would probably
work no matter what, so we can get some usage outside of ext4. Also,
if we want to limit the number of tests, then we don't expect to get
much usage outside of ext4 before v5.5 anyway. I just figure, it's
better to make it work for one person than no one, right?
In any case, I admit it is not a great idea. I just thought it had
some interesting advantages over going in through linux-kselftest that
were worth exploring.
So, we will have to work to make linux-next as the base for new
development and limit the number of tests to where it will be
easier work in this mode for 5.5. We can stage the pull requests
so that kunit lands first followed by tests.
So we are going to encourage maintainers to allow tests in their tree
based on KUnit on the assumption that KUnit will get merged before
there changes? That sounds like a huge burden, not just on us, but on
other maintainers and users.
I think if we are going to allow tests before KUnit is merged, we
should have the tests come in through the same tree as KUnit.
We have a similar situation with kselftest as well. Sub-systems
send tests that depend on their tress separately.
Well it is different if the maintainer wants to send the test in
through their tree, right? Otherwise, it won't matter what the state
of linux-next is and it won't matter when linux-kselftest gets merged.
Or am I not understanding you?
Let's talk about current state. Right now kunit is in linux-next and
we want to add a few more tests. We will have to coordinate the effort.
Once kunit get into mainline, then the need for this coordination goes
down.
Let's focus on the next few weeks first so we can get this into mainline
in 5.5.
The two of us can chat next week and come up with a plan.
thanks,
-- Shuah