linux-kernel - Re: [PATCH RESEND] selftests/ftrace: Improve integration with kselftest runner

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230424214246.3e158fb6@rorschach.local.home>
Date:   Mon, 24 Apr 2023 21:42:46 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH RESEND] selftests/ftrace: Improve integration with
 kselftest runner

On Tue, 11 Apr 2023 12:19:30 +0100
Mark Brown <broonie@...nel.org> wrote:

> 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@...dmis.org>

Shuah, care to take this?

-- Steve