Message-ID: <20111107203255.GF24234@thunk.org>
Date:	Mon, 7 Nov 2011 15:32:55 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Vince Weaver <vince@...ter.net>,
	Anthony Liguori <anthony@...emonkey.ws>,
	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>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to
 test kernels

On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote:
> 
> I'm sure perf developers break the ABI sometimes - that happens
> elsewhere in the kernel as well. However, Ted claimed that perf
> developers use tools/perf as an excuse to break the ABI _on purpose_
> which is something I have hard time believing.

I remember an assertion, probably a year or two ago, probably at the
previous year's kernel summit, that one of the reasons for having the
perf code inline in the kernel was so that synchronized changes could
be made to both the kernel and userspace tool together.  So it's not a
matter of breaking the ABI _on_ _purpose_, it's an assertion that
there is no ABI at all.  Since the perf tool and the kernel tool have
to be built together, so long as a user does that, no harm, no foul.
Recall that Linus has said that he doesn't care about whether or not
something is an ABI; he only care if users code don't perceive
breakage.  If they didn't perceive breakage, then it doesn't matter if
an interface is changed.

So the real question is whether or not this was an excuse to break the
ABI, but whether or not the perf developers acknowledge there is an
ABI at all, and whether it's OK for other developers to depend on the
syscall interface or not.  Actually, though, it shouldn't matter,
because intentions don't matter.

Recall the powertop/ftrace case.  If you expose an interface, and
people start using that interface, then you can't break them, period.
So as far as Vince is concerned, if you have a userspace library which
depends on the perf interface, then you should try out the kernel
after each merge window, and if your library breaks, you should
complain to Ingo and Linus directly, and request that the commit which
broke your tool to be reverted --- because that's the rule; no
breakage is allowed.

As far as kvm-tool being in the kernel, I still don't see particularly
valid arguments for why it should be in the kernel.  It can't be the
perf argument of "we can make simultaneous changes in the userspace
and kernel code", because if those changes break qemu-kvm, then a
complaint to Linus will cause the problem code to be reverted.

As far as the code using the same coding conventions and naming
conventions as the kernel, that to me isn't a particular strong
argument either.  E2fsprogs uses the Signed-off-by lines, and the same
coding conventions of the kernel, and it even has a slightly modified
version of two kernel source file in e2fsprogs (e2fsck/recovery.c and
e2fsck/revoke.c), plus a header file with data structures that have to
be kept in sync with the kernel header file.  But that doesn't make it
"part of the kernel", and it's not a justification for it to be
bundled with the kernel.

Personally, I consider code that runs in userspace as a pretty bright
line, as being "not kernel code", and while perhaps things like
initramfs and the crazy ideas people have had in the past of moving
stuff out of kernel/init.c into userspace might have qualified as
stuff really close to the kernel, something like kvm-tool that runs
way after boot, doesn't even come close.  Wine is another example of
another package that has lots of close kernel ties, but was also not
bundled into the kernel.

The precedent has all mainly been on the "keep the kernel separate"
side of things, and the arguments for bundling it with the kernel are
much weaker, especially since the interface is well-developed, and
there are external users of the interface which means you can't make
changes to the interface willy-nilly.

Indeed, when the perf interface was changing all the time, maybe there
was some convenience to have it be bundled with the kernel, so there
was no need to negotiate interface version numbers, et. al.  But given
how it has to link in so many user space libraries, I personally think
it's fair to ask the question whether now that it has matured, whether
it's time to move it out of the kernel source tree.

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