[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150414125822.GA32761@gmail.com>
Date: Tue, 14 Apr 2015 14:58:22 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>, mingo@...hat.com,
ak@...ux.intel.com, Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
peterz@...radead.org, namhyung@...nel.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
Pekka Enberg <penberg@....fi>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON
event files.)
* Michael Ellerman <mpe@...erman.id.au> wrote:
> On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote:
> > * Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com> wrote:
> >
> > > This is another attempt to resurrect Andi Kleen's patchset so users
> > > can specify perf events by their event names rather than raw codes.
> > >
> > > This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0.
> > > (I fixed minor and not so minor conflicts).
> >
> > So this series shows some progress, but instead of this limited
> > checkout ability I'd still prefer it if 'perf download' downloaded
> > the latest perf code itself and built it - it shouldn't be limited
> > to just a small subset of the perf source code!
>
> Ingo, can you please stop blocking this? It's getting ridiculous.
>
> We've been waiting over 8 months for this to go in.
We just merged a patch series that was first sent in 2013. Some things
take time to get right.
> While we've been waiting most of our users have learnt to use operf
> instead, which doesn't require raw codes.
>
> I would also add that exactly zero users have asked for a feature
> where perf downloads and rebuilds itself. In fact many of them would
> consider that a security breach.
Fetching tracing scripts, plugins or other instrumentation scripts can
be considered a 'security breach' as well. Fetching external tables
(or network access to begin with) can be considered a 'security
breach' as well, depending on how restricted an environment is.
But we don't design our code based on the most restrictive
environments that are hostile to open source concepts!
Unfortunate users that are not allowed to update open source code that
they are using should probably not update it. The other 99.9% of perf
users would benefit from a properly done upgrading/updating feature.
Please stop thinking in terms of restricted, closed environments.
Packaged perf will still work fine for them, and changes will still
trickle down to them.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists