Re: KVM call agenda for Mar 23

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

Avi Kivity wrote:
> 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.
> 

The last item would imply throwing away what qemu.git already cleaned up
- or finally convert the rest. There is no lazy path.

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

One issue of merging blindly is the command line option zoo of qemu-kvm.
I don't think we want this upstream first and then deprecate it quickly
again.

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

I don't think extboot will make it upstream anymore, now that there is
an effort for a gpxe-based virtio boot loader.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]