On Wed, Jun 11, 2025 at 11:36:43AM +0200, Christian Brauner wrote: > Sigh. There's no need to get all high and mighty about this. For once I > actually do write extensive selftests and they do actually catch a lot > of bugs. It's a joke how little selftests we have given the importance > of our apis. Nobody ever gives a flying fsck to review selftests when > they're posted because nobody seems to actually care. Not quite - for me the problem is more on the logistics side; xfstests is a lot more convenient in that respect. To be serious, the main problems are 1) many selftests have non-trivial dependencies on config and spew a lot of noise when run on different configs. 2) very much oriented to case when kernel tree (with build already done) sitting on the box where they are going to be run. Sure, I can tar c .|ssh kvm.virt "mkdir /tmp/linux; cd /tmp/linux; tar x ." and then make kselftest there, but it's still a headache. 3) unlike e.g. xfstests and ltp, you don't get a convenient summary of the entire run. None of that is fatal, obviously, just bloody annoying to deal with at 4am... Yes, I know how to use TARGETS, etc., but IME a test in xfstests is less of a headache on my setup. > > IMO that kind of stuff should be dealt with by creating a temporary directory > > somewhere in /tmp, mounting tmpfs on it, then doing all creations, etc. > > inside that. Then umount -l /tmp/<whatever>; rmdir /tmp/<whatever> will > > clean the things up. > > Sorry, that's just wishful thinking at best and out of touch with how > these apis are used. The fact that you need a private assembly in some > hidden away directory followed by a umount is a complete waste of system > calls for a start. It's also inherently unclean unless you also bring > mount namespaces into the mix. Being able to use detached mount trees is > simple and clean especially for the overlayfs layer case. Huh? I'm talking about the easy-of-teardown for reproducers, nothing else. And the way I'd described above _is_ trivial to set up and tear down cleanly...
