Received-SPF: pass (google.com: domain of linux-kernel+bounces-108940-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 20 Mar 2024 09:29:02 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>, linux-kernel@vger.kernel.org,
 linux-trace-kernel@vger.kernel.org
Subject: Re: [GIT PULL] tracing/tools: Updates for 6.9
Message-ID: <20240320092902.0840c87a@gandalf.local.home>
In-Reply-To: <20f9d90e-454e-448c-989d-84900d380561@kernel.org>
References: <20240318174116.420584-1-bristot@kernel.org>
	<20240319190259.0086706f@gandalf.local.home>
	<20f9d90e-454e-448c-989d-84900d380561@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 20 Mar 2024 13:41:12 +0100
Daniel Bristot de Oliveira <bristot@kernel.org> wrote:

> 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?

Just create a new tag.

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

Yes please.

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

+1

Thanks,


-- Steve