Message-ID: <20111108163331.GJ24234@thunk.org>
Date:	Tue, 8 Nov 2011 11:33:31 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...nel.org>,
	Vince Weaver <vince@...ter.net>, Avi Kivity <avi@...hat.com>,
	"kvm@...r.kernel.org list" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	qemu-devel Developers <qemu-devel@...gnu.org>,
	Alexander Graf <agraf@...e.de>,
	Blue Swirl <blauwirbel@...il.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git
 repository, tools/perf/ and tools/kvm/

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.


> Did you consider it a possibility that out of tree projects that have 
> deep ties to the kernel technically seem to be at a relative 
> disadvantage to in-kernel projects because separation is technically 
> costly with the costs of separation being larger than the advantages 
> of separation?

As the e2fsprogs developer, I live with the costs all the time; I can
testify to the facy that they are very slight.  Occasionally I have to
make parallel changes to fs/ext4/ext4.h in the kernel and
lib/ext2fs/ext2fs.h in e2fsprogs, and we use various different
techniques to detect whether the ext4 kernel code supports a
particular feature (we use the presence or absence of some sysfs
files), but it's really not been hard for us.

> But note that there are several OS projects that succeeded doing the 
> equivalent of a 'whole world' single Git repo, so i don't think we 
> have the basis to claim that it *cannot* work.

There have indeed, and there has speculation that this was one of many
contributions to why they lost out in the popularity and adoption
competition with Linux.  (Specifically, the reasoning goes that the
need to package up the kernel plus userspace meant that we had
distributions in the Linux ecosystem, and the competition kept
everyone honest.  If one distribution started making insane decisions,
whether it's forcing Unity on everyone, or forcing GNOME 3 on
everyone, it's always possible to switch to another distribution.  The
*BSD systems didn't have that safety valve....)


> But why do you have to think in absolutes and extremes all the time? 
> Why not excercise some good case by case judgement about the merits 
> of integration versus separation?

I agree that there are tradeoffs to both approaches, and I agree that
case by case judgement is something that should be done.  One of the
reasons why I've spent a lot of time pointing out the downsides of
integration and the shortcomings in the integration position is that
I've seen advocates claiming that the fact that was perf was
integrated was a precedent that meant that choice for kvm-tool was
something that should not be questioned since tools/perf justified
anything they wanted to do, and that if we wanted to argue about
whether kvm-tool should have been bundled into the kernel, we should
made different decisions about perf.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists