On Wed, Jun 19, 2019 at 06:17:51PM -0700, Frank Rowand wrote:
It does not matter whether KUnit provides additional things, relative to kselftest. The point I was making is that there appears to be _some_ overlap between kselftest and KUnit, and if there is overlap then it is worth considering whether the overlap can be unified instead of duplicated.
From my experience as an author of several kselftests drivers, one
faily complex, and after reviewing the sysctl kunit test module, I disagree with this.
Even if there were an overlap, I'd say let the best test harness win. Just as we have different LSMs that do something similar.
But this is not about that though. Although both are testing code, they do so in *very* different ways.
The design philosophy and architecture are fundamentally different. The *only* thing I can think of where there is overlap is that both can test similar code paths. Beyond that, the layout of how one itemizes tests could be borrowed, but that would be up to each kselftest author to decide, in fact some ksefltests do exist which follow similar pattern of itemizing test cases and running them. Kunit just provides a proper framework to do this easily but also with a focus on UML. This last aspect makes kselftests fundamentally orthogonal from an architecture / design perspective.
After careful review, I cannot personally identify what could be shared at this point. Can you? If you did identify one part, how do you recommend to share it?