linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Agustin Vega-Frias <agustinv@codeaurora.org>
Cc: Andi Kleen <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	timur@codeaurora.org, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC V3 1/3] perf, tools: Support wildcards on pmu name in dynamic pmu events
Date: Wed, 7 Mar 2018 16:58:33 -0300	[thread overview]
Message-ID: <20180307195833.GX3701@kernel.org> (raw)
In-Reply-To: <ca5a79445859ff4fb75b021f84f656f9@codeaurora.org>

Em Wed, Mar 07, 2018 at 02:49:50PM -0500, Agustin Vega-Frias escreveu:
> On 2018-03-07 14:39, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Mar 07, 2018 at 04:05:43PM -0300, Arnaldo Carvalho de Melo
> > escreveu:
> > > Em Wed, Mar 07, 2018 at 04:05:09PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Wed, Mar 07, 2018 at 10:54:15AM -0800, Andi Kleen escreveu:
> > > > > > Sorry about that. That's probably because FNM_EXTMATCH is a GNU extension,
> > > > > > not POSIX, and the Alpine and Android runtimes likely don't implement
> > > > > > that...
> > > > > > I'll send a fix reverting back to the strncmp to ignore the uncore_ prefix,
> > > > > > and dropping that extension.
> > > > >
> > > > > Just don't set it? Even the basic glob patterns are useful.
> > > >
> > > > Or use:
> > > >
> > > > #ifndef FNM_EXTMATCH
> > > > #define FNM_EXTMATCH 0
> > > > #endif
> > > >
> > > > So on systems without it, its not used, while on GNU systems, we have
> > > > that functionality (pretty fancy, someone may need that... ;-))
> > > 
> > > I'll try this route, btw, no need to send more patches for now.
> > 
> > So, with the patch at the end of this message, it works now in those
> > systems:
> > 
> > [root@jouet ~]# dm
> >    1 alpine:3.4                    : Ok   gcc (Alpine 5.3.0) 5.3.0
> >    2 alpine:3.5                    : Ok   gcc (Alpine 6.2.1) 6.2.1
> > 20160822
> >    3 alpine:3.6                    : Ok   gcc (Alpine 6.3.0) 6.3.0
> >    4 alpine:edge                   : Ok   gcc (Alpine 6.4.0) 6.4.0
> >    5 amazonlinux:1                 : Ok   gcc (GCC) 4.8.5 20150623
> > (Red Hat 4.8.5-11)
> >    6 amazonlinux:2                 : Ok   gcc (GCC) 7.2.1 20170915
> > (Red Hat 7.2.1-2)
> >    7 android-ndk:r12b-arm          : Ok   arm-linux-androideabi-gcc
> > (GCC) 4.9.x 20150123 (prerelease)
> >    8 android-ndk:r15c-arm          : Ok   arm-linux-androideabi-gcc
> > (GCC) 4.9.x 20150123 (prerelease)
> >    9 centos:5                      : Ok   gcc (GCC) 4.1.2 20080704
> > (Red Hat 4.1.2-55)
> >   10 centos:6                      : Ok   gcc (GCC) 4.4.7 20120313
> > (Red Hat 4.4.7-18)
> > 
> > I stopped the test at this point to process some more patches, will
> > restart the tests with those extra patches and if all goes well with the
> > other 46 build environments, push upstream, thanks.
> > 
> > - Arnaldo
> > 
> > diff --git a/tools/perf/util/parse-events.y
> > b/tools/perf/util/parse-events.y
> > index 316ac073aa78..18473be7d787 100644
> > --- a/tools/perf/util/parse-events.y
> > +++ b/tools/perf/util/parse-events.y
> > @@ -9,6 +9,13 @@
> >  #define YYDEBUG 1
> > 
> >  #include <fnmatch.h>
> > +/*
> > + * GNU extension, so better define it to 0 for systems such
> > + * as Android and Alpine Linux.
> > + */
> > +#ifndef FNM_EXTMATCH
> > +#define FNM_EXTMATCH 0
> > +#endif
> >  #include <linux/compiler.h>
> >  #include <linux/list.h>
> >  #include <linux/types.h>
> 
> Hey Jiri,
> 
> The downside is that, while the compilation now works on those
> systems, the pattern will not work as intended in them :o(
> Let me cook something and send it ASAP.

Well, do you think this is really a big problem? Even if we add nice
docs?

I haven't tested something that works with this syntax on a capable
system and then on one that doesn't, to see how it would behave,
probably it would say something about a syntax error?

- Arnaldo

  reply	other threads:[~2018-03-07 19:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 14:04 [RFC V3 0/3] perf stat: improvements for handling of multiple PMUs Agustin Vega-Frias
2018-03-06 14:04 ` [RFC V3 1/3] perf, tools: Support wildcards on pmu name in dynamic pmu events Agustin Vega-Frias
2018-03-07 16:02   ` Arnaldo Carvalho de Melo
2018-03-07 17:39     ` Agustin Vega-Frias
2018-03-07 18:54       ` Andi Kleen
2018-03-07 19:05         ` Arnaldo Carvalho de Melo
2018-03-07 19:05           ` Arnaldo Carvalho de Melo
2018-03-07 19:39             ` Arnaldo Carvalho de Melo
2018-03-07 19:49               ` Agustin Vega-Frias
2018-03-07 19:58                 ` Arnaldo Carvalho de Melo [this message]
2018-03-07 20:09                   ` Agustin Vega-Frias
2018-03-07 20:21                     ` Jiri Olsa
2018-03-07 20:33                     ` Arnaldo Carvalho de Melo
2018-03-06 14:04 ` [RFC V3 2/3] perf, tools: Display pmu name when printing unmerged events in stat Agustin Vega-Frias
2018-03-06 14:04 ` [RFC V3 3/3] perf pmu: Auto-merge PMU events created by prefix or glob match Agustin Vega-Frias
2018-03-07 10:04 ` [RFC V3 0/3] perf stat: improvements for handling of multiple PMUs Jiri Olsa
2018-03-07 13:36   ` Arnaldo Carvalho de Melo
2018-03-07 13:51     ` Jiri Olsa
2018-03-07 14:30       ` Arnaldo Carvalho de Melo
2018-03-07 17:09         ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180307195833.GX3701@kernel.org \
    --to=acme@kernel.org \
    --cc=agustinv@codeaurora.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).