Received-SPF: pass (google.com: domain of linux-kernel+bounces-108908-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <20f9d90e-454e-448c-989d-84900d380561@kernel.org>
Date: Wed, 20 Mar 2024 13:41:12 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] tracing/tools: Updates for 6.9
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>, linux-kernel@vger.kernel.org,
 linux-trace-kernel@vger.kernel.org
References: <20240318174116.420584-1-bristot@kernel.org>
 <20240319190259.0086706f@gandalf.local.home>
Content-Language: en-US, pt-BR, it-IT
From: Daniel Bristot de Oliveira <bristot@kernel.org>
In-Reply-To: <20240319190259.0086706f@gandalf.local.home>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 3/20/24 00:02, Steven Rostedt wrote:
> On Mon, 18 Mar 2024 18:41:13 +0100
> Daniel Bristot de Oliveira <bristot@kernel.org> wrote:
> 
>> Steven,
>>
>> Tracing tooling updates for 6.9
>>
>> Tracing:
>>         - Update makefiles for latency-collector and RTLA,
>>           using tools/build/ makefiles like perf does, inheriting
>>           its benefits. For example, having a proper way to
>>           handle dependencies.
>>
>>         - The timerlat tracer has an interface for any tool to use.
>>           rtla timerlat tool uses this interface dispatching its
>>           own threads as workload. But, rtla timerlat could also be
>>           used for any other process. So, add 'rtla timerlat -U'
>>           option, allowing the timerlat tool to measure the latency of
>>           any task using the timerlat tracer interface.
>>
>> Verification:
>>         - Update makefiles for verification/rv, using tools/build/
>>           makefiles like perf does, inheriting its benefits.
>>           For example, having a proper way to handle dependencies.
>>
>>
>> Please pull the latest trace-tools-v6.9 tree, which can be found at:
>>
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/bristot/linux.git
>> trace-tools-v6.9
> 
> Looks like you just built on top of a random commit from Linus's tree:

yeah :-/

> commit f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
> Merge: 906a93befec8 8f06fb458539
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Sun Mar 17 16:59:33 2024 -0700
> 
>     Merge tag 'i3c/for-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux
> 
> Linus prefers basing off of real tags or previous pulls from us.

Ack, took note. I will do on top v6.8 tag.

> Can you rebase your changes on v6.8 and resend?
> 
>   $ git checkout v6.8
>   $ git cherry-pick f6cef5f8c37f58a3bc95b3754c3ae98e086631ca..trace-tools-v6.9
> 
> Appears to work fine.

questions: when something go wrong in a pull request....

	- Should I keep the old tag, and then do another one with -2
	  (it seems you do like this), or delete the old tag and send it again
	  with the same name?

	- Should I resend the PULL request with something in the log or
	  at the Subject saying it is a v2 of the pull request?

I could ask via chat, but I think it is good for the community to
have access to these info.

Thanks!
-- Daniel

> Thanks!
> 
> -- Steve