Hi, On Fri, 2025-06-27 at 10:43 +0200, Thomas Weißschuh wrote: > On Fri, Jun 27, 2025 at 09:29:12AM +0200, Benjamin Berg wrote: > > On Fri, 2025-06-27 at 06:33 +0200, Thomas Weißschuh wrote: > > > On Thu, Jun 26, 2025 at 09:57:12PM +0200, Benjamin Berg wrote: > > > > so I saw the UAPI testing framework patches and wondered whether I could > > > > hack up a kunit test for userspace signal mcontext handling. I already > > > > had some code, but never knew where to include it. Having it as a kunit > > > > test in this way seems nice as it makes running the test really simple. > > > > > > Nice to hear that you find it useful. > > > > > > > This is a very rough attempt with an extra patch to add sigaction > > > > support as that is needed by the test. > > > > > > > > Note that this type of test could possibly be shared with the x86 > > > > architecture (though UM does not support all features). > > > > > > Can the expected feature detection be performed at runtime? > > > If so I would write the test as x86 kselftest in > > > tools/testing/kselftests/x86/ > > > and then also hook it up for kunit on UML and x86. > > > This gives you the advantages of all worlds. > > > > > > For an example see [0]. That is still based on an old version of the > > > framework, > > > so can't be used as-is. But you should get the idea. > > > > That looks nice, and you do support both x86 and um there! > > > > Many of those checks should be simple as syscalls will return an error > > (modify_ldt should return -ENOSYS for example). For more arcane things > > one could e.g. add "(um)" into AT_PLATFORM or just disable the kunit > > test for the um architecture. > > Sounds good. > > > This is a nice development, I absolutely expect to find some bugs in um > > this way. > > I do so, too :-) > > https://lore.kernel.org/lkml/20250617-uml-tick-timer-v1-1-01aab312f...@linutronix.de/
Ah, yes, that one :-) > To be honest if there are going to be a bunch of issues on UML, > I'd prefer to drop the UML bits from my submissions. > I'm not familiar with UML and can't really fix the fallout. > Then you can wire up the tests with a few lines and handle the fallout at > your convenience. > > Or we gate the testcases behind BROKEN/EXPORT on UML in the beginning. > > Does this sound reasonable? Not sure how to gate them, but I do like the idea of being able to enable them using only minor modifications or even a Kconfig option to see what happens on UM. Benjamin > > <snip> > > > Thomas >
