Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

Ingo Molnar
2011-11-10T07:49:31Z

* Américo Wang <xiyou.wangcong@gmail.com> wrote:

> On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > So i think you should seriously consider moving your projects
> > *into* tools/ instead of trying to get other projects to move out
> > ...
> >
> > You should at least *try* the unified model before criticising it
> > - because currently you guys are preaching about sex while having
> > sworn a life long celibacy ;-)
>
> Ingo, this is making Linux another BSD... manage everything in a
> single tree...

It's not an all-or-nothing prospect. Linux user-space consists of
well in excess of 200 MLOC code. The kernel is 15 MLOC.

I think the system-bound utilities that 'obviously' qualify for
kernel inclusion are around 1 MLOC in total size, i.e. less than 0.5%
of all user-space.

> Also, what is your criteria for merging a user-space project into
> kernel tree?

Well, my criteria go roughly along these lines:

1) The developers use that model and are productive that way and
produce a tool that has a significant upside.

2) There's significant Linux-specific interactions between the
user-space project and the kernel.

3) The code is clean, well designed and follows the various
principles laid out in Documentation/CodingStyle and
Documentation/ManagementStyle so that it can be merged into a
prominent spot in the kernel tree and the project is ready to
live with the (non-trivial!) consequences of all that:

- the project does -stable kernel backports of serious bugs

- the project follows a strict "no regressions" policy

- the project follows the kernel release cycle of 'Winter',
'Spring', 'Summer' and 'Autumn' releases and follows the
merge window requirements and implements the post-rc1
stabilization cycle.

These are not easy requirements and i can well imagine that many
projects, even if they qualified on all other counts, would prefer to
stay out of tree than be subject to such strict release engineering
constraints.

Also, the requirements can be made stricter with time, based on
positive and negative experiences. Projects can 'die' and move out of
the kernel as well if the kernel repo did not work out for them. As
long as it's all done gradually and on a case by case basis Linux can
only benefit from this.

Thanks,

Ingo