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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 19 Jul 2014 11:51:04 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	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


* 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.

Your suggestions so far lose those benefits, unnecessarily, and 
without explanation given.

So unless you can come up with a better approach, this is the way to 
implement this feature.

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/