[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 12:50 PM, Jan Kiszka wrote:
> 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.
> >
> >      
> So the benefit would be less merge conflicts/regressions on
> qemu-kvm.git? But you may break non-x86 KVM support in upstream as it
> already uses the cleaned up kvm subsystem. /me is not immediately
> convinced...
>    

The benefit would be that qemu-kvm.git would become a staging tree 
instead of the master repository for kvm users.  As an example, we 
wouldn't have any bisectability problems.  kvm features would need to be 
written just once.


> We are more than half-way through this, so let's focus efforts for the
> last bits that make the difference widely negligible. This investment
> should pay off rather quickly.
>    

If we merge now, we merge the half-completed effort so we don't lose 
anything.  However, if we can complete the merge quickly, I'm all for 
it.  I don't want to introduce the ugliness into qemu.git any more than 
you do.

Note, the above discussion ignores extboot and device assignment, but 
let's focus on the thorny bits first.

--
error compiling committee.c: too many arguments to function