On Fri, Apr 18, 2025 at 10:29:19PM -0000, Joel Fernandes wrote:
Hello, Paul,
On Fri, 18 Apr 2025 22:26:17 GMT, "Paul E. McKenney" wrote:
On Fri, Apr 18, 2025 at 08:32:46PM +0200, Miguel Ojeda wrote:
On Fri, Apr 18, 2025 at 8:04 PM Paul E. McKenney paulmck@kernel.org wrot
e:
Suppose we fired up a guest OS and captured the console output. Is ther
e
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". ;-)
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.
Thanx, Paul