From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: KVM call agenda for Mar 23
Date: Tue, 23 Mar 2010 07:45:47 -0500
Message-ID: <4BA8B7FB.2050103@codemonkey.ws>
References: <20100323061140.GN29498@x200.localdomain> <4BA88A6F.2050703@web.de> <4BA88F5D.6040008@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jan Kiszka <jan.kiszka@web.de>, Chris Wright <chrisw@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gw0-f46.google.com ([74.125.83.46]:55596 "EHLO
	mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750907Ab0CWMpy (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 23 Mar 2010 08:45:54 -0400
Received: by gwaa18 with SMTP id a18so1466757gwa.19
        for <kvm@vger.kernel.org>; Tue, 23 Mar 2010 05:45:54 -0700 (PDT)
In-Reply-To: <4BA88F5D.6040008@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/23/2010 04:52 AM, Avi Kivity wrote:
> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>> Chris Wright wrote:
>>> Please send in any agenda items you are interested in covering.
>>>
>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI 
>>> patches.
>>>
>> - state and roadmap for upstream merge of in-kernel device models
>>    (looks to me like this central merge effort is stalled ATM)
>
> - alternative path of merging qemu-kvm.git's implementation as is and 
> cleaning it up in qemu.git.
>
> For kvm.git, I wouldn't dream of merging something with outstanding 
> issues and cleaning them up "later", but the situation is somewhat 
> different with qemu vs qemu-kvm.

I don't think we can pull in:

  - extboot
  - ia64
  - in-kernel pit[1]
  - associated command line options
  - device passthrough

The question is, if we dropped those things, would people actually use 
qemu.git instead of qemu-kvm.git.  If the answer is "no", what set of 
things do we need in order for people to focus on qemu.git instead of 
qemu-kvm.git.

[1] I'd like to revisit this discussion.  We originally went the 
in-kernel pit route because of difficulties changing qemu.  That's a bad 
reason to put something in the kernel.  I'd prefer to see us fix qemu.  
After that, we can look at in-kernel pit and see if there are any 
remaining advantages (like performance).  If it's significant, we can 
still merge in-kernel pit.

Regards,

Anthony Liguori