Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)

[Ingo Molnar]

* Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:

> On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote:
> > * Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/