On Wed, 12 Feb 2025 at 06:43, Tamir Duberstein tamird@gmail.com wrote:
On Tue, Feb 11, 2025 at 5:38 PM Boqun Feng boqun.feng@gmail.com wrote:
Hi Tamir,
Hi Boqun, thanks for taking a look.
On Mon, Feb 10, 2025 at 10:59:12AM -0500, Tamir Duberstein wrote:
Convert this unit test to a KUnit test.
I would like to know the pros and cons between kunit tests and kselftests, maybe someone Cced can answer that? It'll be good to put these in the commit log as well.
David Gow gave a pretty detailed answer in https://lore.kernel.org/all/CABVgOS=KZrM2dWyp1HzVS0zh7vquLxmTY2T2Ti53DQADrW+... for a similar patch.
That previous answer covers a lot, but while I think the advantages (better tooling, easy architecture emulation, etc) are covered, I'll add a few extra caveats specific to this test here.
KUnit is really better suited to "unit tests" rather than "stress tests", and does have some limits when tests span multiple threads (assertions cannot kill other threads, the test context is not automatically applied, etc).
I don't think these would preclude you from using KUnit for ww_mutex testing -- and people have done multithreaded stress tests in KUnit in the past if they really want to, it's definitely a trade-off rather than a strict win, so it may make sense if as maintainers you are already familiar with or want to use KUnit, but definitely is up to you.
David, what do you think about enumerating these reasons in the KUnit documentation? This is the 3rd of these patches that has received this question. It'd be a shame to have every commit enumerate KUnit's reasons for being.
We have some existing documentation as to when KUnit and kselftest are more appropriate as a part of the 'Kernel Testing Guide' in Documentation/testing-overview.rst (though it focuses on the underlying differences in goals, rather than 'look at all of these useful features'), as well as an overview of why KUnit is useful on the KUnit webpage at http://kunit.dev/ (though without the direct kselftest comparison).
My hope was that porting tests from one framework to the other should be a rare, probably one-off occurrence, so the focus should be more on writing new tests, but clearly what we have is insufficient. And ideally some of the advantages of KUnit, particularly in the standardisation and tooling support, will continue to make their way to kselftest, so hopefully some of the advantages of KUnit will disappear.
Nevertheless, I'll see if there's anything specific we want to add about test porting.
Cheers, -- David