linux-kernel - Re: [GIT PULL] tracing/tools: Updates for 6.9

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240320092902.0840c87a@gandalf.local.home>
Date: Wed, 20 Mar 2024 09:29:02 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Daniel Bristot de Oliveira <bristot@...nel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [GIT PULL] tracing/tools: Updates for 6.9

On Wed, 20 Mar 2024 13:41:12 +0100
Daniel Bristot de Oliveira <bristot@...nel.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@...nel.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@...ux-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