[lkml]   [2009]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] Performance Counters for Linux

    * Marcel Holtmann <> wrote:

    > Hi Ingo,
    > > > What the "keep it in the kernel sources" approach hopefully allows is
    > > >
    > > > - taking advantage of new features in a timely manner.
    > > >
    > > > NOT with some ABI breakage, but simply things like supporting a
    > > > new CPU architecture or new counters. The thing that oprofile
    > > > failed at so badly in my experience.
    > > >
    > > > - Make it easier for developers, and _avoiding_ the horrible
    > > > situation where you have two different groups that don't talk
    > > > well to each other because one is a group of user-space
    > > > weenies, and the other is a group of manly kernel people, and
    > > > there is no common ground.
    > >
    > > Yes, very much agreed.
    > >
    > > Btw., here are a couple of other arguments why i find it useful to
    > > have the tools/perf/ in the kernel repo:
    > >
    > > 1) Super-fast and synchronized release cycles
    > >
    > > The kernel is one of the fastest moving packages in Linux - most
    > > user-space packages have (much!) longer release cycles than 3
    > > months.
    > that might be true for some projects, but for others this is
    > wrong. You are just making an assumption out of thin air.
    > > A tight release schedule forces a certain amount of release
    > > discipline on tooling as well - so i'm glad that the two will be
    > > coupled. It's so easy for a promising tool to degrade into
    > > tinkerware with odd release cycles with time - if it's part of
    > > the kernel then at least the release cycles wont be odd but at
    > > precise 3 months.
    > And you can't do that within a perf.git tree on
    > because?

    We actually tried the tools as separate code, and for the first
    three months of the project we only got three contributions - while
    the kernel code was essentially finished. (Pekka reported a similar
    experience in this thread, with another tool that has close kernel

    Once we moved it into the same repo as the kernel code (three months
    ago), the patches started flowing in - at an amazing rate. We now
    have a dozen contributors, most of them kernel developers, and we
    have over a hundred good changes to the tools - in just another 3

    The key difference was the location of the tools. It is very
    convenient and productive to have a shared repository for a project
    that frequently involves both kernel and tool changes.

    So my point is: this model clearly works in practice and all the
    current tools/perf/ contributors like this kind of coding

    Most of your arguments seem to center around the notion that it
    could all be done in a separate repo too and that such a repo could
    be run as well as the Linux kernel. If you think you could do it
    even better in a separate repo you are certainly free to try it.


     \ /
      Last update: 2009-06-11 23:17    [W:0.024 / U:31.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site