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 PHC | |
Open Source and information security mailing list archives
| ||
|
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/
Powered by blists - more mailing lists