* Andi Kleen <[email protected]> wrote:
> Ingo Molnar <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
