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

[Jan Kiszka]

On 2011-11-04 16:16, Sasha Levin wrote:
> 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.

This can happen if the kernel API went totally wrong on the first run.
It happens, but not frequently. Or do you see many examples for this in
KVM's history?

I don't remember finding this particularly problematic for any of my own
patch sets. If the API is controversial, you usually try to get that
conceptually resolved instead of updating all bits over and over again.
Once the API is accepted, changes to the implementations become
independent anyway.

> 
> 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 :)

Synching headers has become trivial these days (reloading updated KVM
modules may take more steps ;) ).

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

I can't imagine that the ability to do a single 'make' for a change that
remains split nevertheless justifies merging more user land into the
kernel. You can always set up a meta project for this.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/