linux-kernel - Re: [PATCH 09/13] perf tools: Add perf download to download event files

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1407287780.32238.3.camel@concordia>
Date:	Wed, 06 Aug 2014 11:16:20 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Jiri Olsa <jolsa@...nel.org>,
	linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH 09/13] perf tools: Add perf download to download event
 files

On Sat, 2014-07-19 at 11:51 +0200, Ingo Molnar wrote:
> * Andi Kleen <andi@...stfloor.org> wrote:
> 
> > Ingo Molnar <mingo@...nel.org> writes:
> > >
> > > We want these description files to be in the perf source code, 
> > > somewhere in tools/perf/live-config/arch/x86/ or so, and installed 
> > > during 'make install' - i.e. part of perf project and installed in 
> > > ~/.debug or ~/.perf or so.
> > 
> > I don't think that's a good idea. It would recreate all the 
> > problems oprofile has with out of date event lists. Already
> > proven to not work well.
> 
> That's true only if you ignore my second suggestion:
> 
> > > Those files could be refreshed via 'perf download' and could be 
> > > accessible via kernel.org as well, 'perf download' should pick up 
> > > these files from Linus's latest git repository (via the HTTP 
> > > namespace).
> > 
> > I have doubts a gitweb server is a good way to distribute 
> > potentially high volume / high access data.
> 
> I don't buy that concern either, because typically humans will trigger 
> the refresh - just like clicking on a link to refresh. In any case, if 
> it starts being a problem in practice we can reconsider, it's not a 
> reason to not do it.
> 
> > However getting a more neutral space is fine.
> > 
> > It would be fine to put it elsewhere on kernel.org.
> > I can ask for a space.
> 
> The beauty of my approach is to:
> 
>  1) integrate the descriptions into the project, so that developers 
>     are well aware of them and keep them uptodate - while considering 
>     all the other perf features the kernel may offer.
> 
>  2) have them update automatically as we update the primary source, in 
>     a single place.

Another benefit of having the events installed as part of perf is that they are
usable on machines that don't have access to the internet.

Even if some of the event descriptions are out of date, that is still
preferable to having no events on such machines.

cheers


--
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/