On Sun, Oct 6, 2019 at 10:18 AM Linus TorvaldsAdding a couple more tests will only help in the long run. The idea is
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
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.
Yes.
At the same time, I don't think it needs to be even that fancy. Even
if it's not a stable branch that gets shared between different
developers, it would be good to just have people do a "let's try this"
throw-away branch to use the kunit functionality and verify that
"yeah, this is fairly convenient for ext4".
It doesn't have to be merged in that form, but just confirmation that
the infrastructure is helpful before it gets merged would be good.
I thought we already had done this satisfactorily.
We have one proof-of-concept test in the branch in the kselftest repo
(proc sysctl test) that went out in the pull request, and we also had
some other tests that were not in the pull request (there is the ext4
timestamp stuff mentioned above, and we also had one against the list
data structure), which we were planning on sending out for review once
Shuah's pull request was accepted. I know the apparmor people also
wrote some tests that they said were useful; however, I have not
coordinated with them on upstreaming their tests. I know of some other
people who are using it, but I don't think the tests are as far along
for upstreaming.
The point is: I thought we had plenty of signal that KUnit would be
useful to have merged into the mainline kernel. I thought the only
reason it was rejected for 5.4 was due to the directory name issue
combined with bad timing.