linux.git - Linus' kernel tree

Age	Commit message (Collapse)	Author
2024-05-06	tracing/selftests: Default to verbose mode when running in kselftest	Mark Brown
	In order to facilitate debugging of issues from automated runs of the ftrace selftests turn on verbose logging by default when run from the kselftest runner. This is primarily used by automated systems where developers may not have direct access to the system so defaulting to providing diagnostic information which might help debug problems seems like a good idea. When tests pass no extra output is generated, when they fail a full log of the test run is provided. Since this really is rather verbose when there are a large number of test failures or output is slow (eg, with a serial console) this could substantially increase the run time for the tests which might present problems with timeout detection for affected systems, hopefully we keep the tests running well enough that this is not too much of an issue. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-05-08	selftests/ftrace: Improve integration with kselftest runner	Mark Brown
	The ftrace selftests do not currently produce KTAP output, they produce a custom format much nicer for human consumption. This means that when run in automated test systems we just get a single result for the suite as a whole rather than recording results for individual test cases, making it harder to look at the test data and masking things like inappropriate skips. Address this by adding support for KTAP output to the ftracetest script and providing a trivial wrapper which will be invoked by the kselftest runner to generate output in this format by default, users using ftracetest directly will continue to get the existing output. This is not the most elegant solution but it is simple and effective. I did consider implementing this by post processing the existing output format but that felt more complex and likely to result in all output being lost if something goes seriously wrong during the run which would not be helpful. I did also consider just writing a separate runner script but there's enough going on with things like the signal handling for that to seem like it would be duplicating too much. Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Tested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>