Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 17 Oct 2019 10:13:25 -0300
From:   Arnaldo Carvalho de Melo <acme@redhat.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     linux-tip-commits@vger.kernel.org,
        Adrian Hunter <adrian.hunter@intel.com>,
        Brendan Gregg <brendan.d.gregg@gmail.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Luis =?iso-8859-1?Q?Cl=E1udio_Gon=E7alves?= <lclaudio@redhat.com>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [tip: perf/core] perf trace: Introduce --filter for tracepoint
 events
Message-ID: <20191017131325.GB3437@redhat.com>
References: <tip-95bfe5d4tzy5f66bx49d05rj@git.kernel.org>
 <157111750352.12254.17113253973879925388.tip-bot2@tip-bot2>
 <20191017071205.GA14441@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191017071205.GA14441@zn.tnic>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Em Thu, Oct 17, 2019 at 09:12:05AM +0200, Borislav Petkov escreveu:
> On Tue, Oct 15, 2019 at 05:31:43AM -0000, tip-bot2 for Arnaldo Carvalho de Melo wrote:
> > The following commit has been merged into the perf/core branch of tip:

> > Commit-ID:     d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> > Gitweb:        https://git.kernel.org/tip/d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> > Author:        Arnaldo Carvalho de Melo <acme@redhat.com>
> > AuthorDate:    Tue, 08 Oct 2019 07:33:08 -03:00
> > Committer:     Arnaldo Carvalho de Melo <acme@redhat.com>
> > CommitterDate: Wed, 09 Oct 2019 11:23:52 -03:00

> > perf trace: Introduce --filter for tracepoint events

> > Similar to what is in 'perf record', works just like there:

> >   # perf trace -e msr:*
> >    328.297 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.302 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.306 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.317 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.322 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.327 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.331 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.336 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.340 :0/0 ^Cmsr:write_msr(msr: FS_BASE, val: 140240388381888)
 
> I wonder if you guys can force this val:'s format to be always hex?
> Because MSR values are a lot more "natural" in hex...

Sure, I'll get there, for now its just setting scnprintf/strtoul helpers
based on tracepoint argument name and/or type.

But just like for syscalls, we'll get to have a way to specify that
'val', specifically for msr:write_msr, or sometimes, for the tracepoint
system part ('msr' in this case) should be formatted in some way.

For syscalls there is even provision for some args to be formmated based
on the value present in another arg, think ioctls, all this is being
refitted to support tracepoints other than the syscall ones.

The 'msr' one was the super low hanging fruit, we look just at its name,
no checks on what tracepoint it is, and we were investigating some stuff
at Red Hat and Marcelo said it was a PITA to be doing the lookups in
msr-index.h everytime he needed for look for those in traces, so came
first. :-)

- Arnaldo