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

[Ingo Molnar]

* John Kacur <address@hidden> wrote:

> On Tue, 8 Nov 2011, Ted Ts'o wrote:
> 
> > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:

> > > I guess you can do well with a split project as well - my main 
> > > claim is that good compatibility comes *naturally* with 
> > > integration.
> > 
> > Here I have to disagree; my main worry is that integration makes 
> > it *naturally* easy for people to skip the hard work needed to 
> > keep a stable kernel/userspace interface.
> > 
> > The other worry which I've mentioned, but which I haven't seen 
> > addressed, is that the even if you can use a perf from a newer 
> > kernel with an older kernel, this causes distributions a huge 
> > amount of pain, since they have to package two different kernel 
> > source packages, and only compile perf from the newer kernel 
> > source package.  This leads to all sorts of confusion from a 
> > distribution packaging point of view.
> > 
> > For example, assume that RHEL 5, which is using 2.6.32 or 
> > something like that, wants to use a newer e2fsck that does a 
> > better job fixing file system corruptions.  If it were bundled 
> > with the kernel, then they would have to package up the v3.1 
> > kernel sources, and have a source RPM that isn't used for 
> > building kernel sources, but just to build a newer version of 
> > e2fsck.  Fortunately, they don't have to do that.  They just pull 
> > down a newer version of e2fsprogs, and package, build, test, and 
> > ship that.
> > 
> > In addition, suppose Red Hat ships a security bug fix which means 
> > a new kernel-image RPM has to be shipped.  Does that mean that 
> > Red Hat has to ship new binary RPM's for any and all tools/* 
> > programs that they have packaged as separate RPM's?  Or should 
> > installing a new kernel RPM also imply dropping new binaries in 
> > /usr/bin/perf, et. al? There are all sorts of packaging questions 
> > that are raised integration, and from where I sit I don't think 
> > they've been adequately solved yet.
> >
>  
> This in practice is not a big deal.
> 
> There are many approaches for how the RPM can be built, but basically
> getting the perf source is just a matter of
> make perf-tar-src-pkg or friends such as
> make perf-tarbz2-src-pkg
> which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2
> respectively which can be used for the src rpms. This tar ball can be used
> as a separate package or subpackage.

Great - the 'perf is impossible for distros' was a common counter 
argument early in the perf project's lifetime - i'm glad it turned 
out to be bogus in practice.

Would it further simplify distro side life if all utilities deeply 
related to the kernel got built together and came in a single well 
working package? kutils-3.2.0-rc1.rpm or such.

They would always upgrade together with the kernel so there would 
never be any forced backporting or separate errata pressure, beyond 
the existing flow of -stable fixes.

We do -stable fixes for tools/perf/ as well, for stability/security 
fixes, naturally - other tools would have to follow the regular 
kernel maintenance process to manage high priority fixes.

Basically distros could rely on the kernel and its utilities being a 
coherent whole, which is expected to work together, which is 
maintained and built together and which, if it regresses, is handled 
by the regular -stable kernel regressions process with high priority.

I expect it would grow one by one - it's not like we can or want to 
force utilities to go into the kernel proper. I'd also expect that 
new tools would be added initially - not existing ones moved. My 
question to you would rather be, would it make the life of distro 
release engineers gradually easier if this space grew gradually over 
the years, adding more and more critical tool functionality?

Thanks,

        Ingo