On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o <tytso(a)mit.edu> wrote:
On Fri, Oct 04, 2019 at 06:18:04PM -0700, Brendan Higgins wrote:
> > 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.
> Sure, I was just thinking that getting other people to write the tests
> would be better. Since not only is it then useful to someone else, it
> provides the best possible exercise of KUnit.
Well, one thing we *can* do is if (a) if we can create a kselftest
branch which we know is stable and won't change, and (b) we can get
assurances that Linus *will* accept that branch during the next merge
window, those subsystems which want to use kself test can simply pull
it into their tree.
Yeah, I can't think of any reason that you haven't outlined already
why that might not work, but that seems kind of like circumventing
We've done this before in the file system world, when there has
some common set of changes needed to improve, say, Direct I/O, where
the changes are put into a standalone branch, say, in the xfs tree,
and those file systems which need it as a building block can pull it
into their tree, and then add the changes needed to use those changes
into their file system git tree. These changes are generally not
terribly controversial, and we've not had to worry about people want
to bikeshed the changes.
There is a risk with doing this of course, which is that if the branch
*is* controversial, or gets bike-shedded for some reason, then Linus
gets upset and any branches which depended on said branch will get
rejected at the next merge window. Which is the requirement for (a)
and (b) above. Presumably, the fact that people were unwilling to let
Kunit land during this merge window might will *because* we think more
changes might be pending?
My understanding, based on what I have been told, is that we were
simply unlucky with the timing when Linus pulled the branch in the
first week of the 5.4 merge window (Friday), such that once I fixed
the directory naming issue, the updated changes didn't spend enough
time in linux-next. And now with this issue fixed and KUnit back in
linux-next, if nothing interesting happens between now and 5.5, it
will be accepted in the 5.5 merge window. I do not think that anyone
is expecting anymore changes before merging.
Shuah, Linus, is my understanding correct?
The other thing I suppose I can do is to let the ext4 kunit tests
in ext4 tree, but with the necessary #ifdef's around things like
"#include <kunit/test.h>" so that the build won't blow up w/o kunit
changes being in the tree that I'm building. It means I won't be able
to run the tests without creating a test integration branch and
merging in kunit by hand, which will super-annoying, of course. And
if some of the bike-shedding is in Kunit's interfaces, then that
becomes problematic as well, since any tests that are in ext4.git tree
might change if people want to rename Kunit's publically exported
functions (for example).
Yeah, that seems even worse. I'm sorry to have caused this frustration.
> Hey Ted, do you know if that ext4 timestamp test can go in
> linux-kselftest? It seemed fairly self-contained. Or is that what you
> were saying wouldn't work for you?
Well, I was hoping that we might start creating more tests beyond just
the ext4 timestamp tests....
Okay, that's what I thought (and what I hoped) you were saying :-)
I hope we can figure out something that will work for you. Or
otherwise that you won't mind waiting until 5.5.