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_kernel >>>> >>> Alternatively, 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. thanks, - Joel
