On Sat, Apr 19, 2025 at 06:24:56PM -0400, Joel Fernandes wrote:
Hi Paul,
On 4/18/2025 6:45 PM, Paul E. McKenney wrote:
Suppose we fired up a guest OS and captured the console output. Is there a way to make that guest OS shut down automatically at the end of the test and to extract the test results?
Ah, sorry, I thought you were already doing something like that, i.e. that perhaps you could reuse some kernel build you already had and avoiding a full rebuild/mrproper. The KUnit Python script uses QEMU and parses the results; e.g. you could look for the results lines like:
# Totals: pass:133 fail:0 skip:0 total:133 ok 2 rust_doctests_kernelAlternatively, I could clone a copy of the current archive into a temporary directory, "make mrproper" there, run kunit normally, then clean up the temporary directory. Extra storage, but quite a bit more robust and user-friendly.
Just to be on the same page, is the concern about the slowness of mrproper or that it kills the kernel build artifacts requiring a clean build?
It blows away things like tags and cscope databases. Me, I have my cscope databases elsewhere, but lots of people build them for their live git repos. And they are (quite understandably) unhappy when their source-code browsing tools are blown away by some random test doing an unsuspected "make mrproper". 😉
Cool. One thing is, running other test modes in torture.sh also reconfigures the kernel and potentially recompiles the entire kernel as a result. So if someone is already having their own kernel build, running torture.sh already may cause them to have to do a full rebuild, AFAICS. But yes, and to your point, the cscope DB and stuff may get blown away for additional disruption.
What kind of improvement are we looking for and why would this patch in its current form not work?
For the near term, I am OK with its current form because it is non-default. Longer term, though, we need it to be tested by default, and that means making it avoid undoing people's work. My short-term approach is to enable this test on my employer's test systems, which have Rust set up correctly, and skip it on my laptop, which has a strange FrankenRust due to my early playing around with that language.
Or we teach kunit.py to not require a mrproper? :-) I wonder why it needs to do that. I may run into that too considering my other kernel project requires me to mess around with rust.
They might have a good reason for that "make mrproper", but it does sound like a good avenue to investigate. Otherwise, as noted earlier, my thought is to clone the repo into a temp directory, run "make mrproper" there, continue being a non-special user of kunit, and avoid messing up people's databases and tags.
Thanx, Paul