Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1e2b5a9e-9e92-6394-74fd-18dae2ed0712@linuxfoundation.org>
Date:   Mon, 27 Mar 2023 13:43:15 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH] selftests/ftrace: Improve integration with kselftest
 runner
Content-Language: en-US
To:     "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
        Mark Brown <broonie@kernel.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org,
        Shuah Khan <skhan@linuxfoundation.org>
References: <20230302-ftrace-kselftest-ktap-v1-1-a84a0765b7ad@kernel.org>
 <20230319232438.786c46feaf9bb7ddcb78a731@kernel.org>
From:   Shuah Khan <skhan@linuxfoundation.org>
In-Reply-To: <20230319232438.786c46feaf9bb7ddcb78a731@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/19/23 08:24, Masami Hiramatsu (Google) wrote:
> Hi Mark,
> 
> On Mon, 06 Mar 2023 15:35:10 +0000
> Mark Brown <broonie@kernel.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.
> 
> This looks great! and is what we need.
> 
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Tested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> 
> Thank you!
> 
>>

Steve,

Okay to pick this up for the Linux 6.4?

thanks,
-- Shuah