linux-kernel - Re: [RFC/GIT PULL] Linux KVM tool for v3.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1320419814.3334.45.camel@lappy>
Date:	Fri, 04 Nov 2011 17:16:54 +0200
From:	Sasha Levin <levinsasha928@...il.com>
To:	Jan Kiszka <jan.kiszka@...mens.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Subject: Re: [RFC/GIT PULL] Linux KVM tool for v3.2

On Fri, 2011-11-04 at 15:42 +0100, Jan Kiszka wrote:
> On 2011-11-04 14:32, Pekka Enberg wrote:
> > I know you don't see the benefits of integrated code base but I as a
> > developer do.
> 
> IIRC, this discussion still lacks striking, concrete examples from the
> KVM tool vs. QEMU development processes.

I'll give a current example: Michael and Rusty are currently considering
a change in the virtio spec (allowing MMIO config BARs - but thats
irrelevant).

I'll quote what Anthony said about how he sees the big picture of how
this change is going to be implemented - something which we all agree
with:

On Thu, 2011-11-03 at 09:37 -0500, Anthony Liguori wrote:
> Well, what's needed before the spec is changed is an interesting question, but I 
> think the main thing is, don't commit any virtio ABI changes to vhost, QEMU, 
> NKT, or the kernel until the spec for the change has been committed.
> 
> It would be nice to have a working implementation before committing a spec 
> change.  Even nicer would be to have Acked-by's a maintainer in each area affected.

Which is pretty smart. Get a working implementation before we commit to
a spec.

Now, how would the development process look when the trees aren't
integrated? You'd try to get the kernel side stabilized, then you'd do
your usermode changes, go back to the kernel patches to fix bugs and
things people missed, which would require in turn new patches to the
usermode part, and so until you get 5-6 versions (best case) of this
change in *each* tree.

Add some technical difficulties which just make it uglier, such as
having to copy over new kernel headers into the usermode tool for each
new version you want to send (linux-headers/ dir in QEMU) and you get a
process which is not that pretty anymore :)

How would it look for an integrated project? You'd be working on the
same codebase, one series of patches would take care of both the kernel
changes and the userspace changes, this would speed up iterations and
make testing quite easier.

-- 

Sasha.

--
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/