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
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 <>
To:	Andi Kleen <>
Cc:	Jiri Olsa <>,,
	Arnaldo Carvalho de Melo <>,
	Peter Zijlstra <>,
	Thomas Gleixner <>,
	Arnaldo Carvalho de Melo <>
Subject: Re: [PATCH 09/13] perf tools: Add perf download to download event

* Andi Kleen <> wrote:

> Ingo Molnar <> 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 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
> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists