qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] State of KVM bits in linux-headers


From: Jan Kiszka
Subject: Re: [Qemu-devel] State of KVM bits in linux-headers
Date: Wed, 11 Jan 2012 20:56:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-01-11 20:52, Anthony Liguori wrote:
> On 01/11/2012 01:48 PM, Jan Kiszka wrote:
>> On 2012-01-11 20:46, Alexander Graf wrote:
>>>
>>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>>
>>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>>
>>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>>> some mess on everyone's side.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>>> and also the header. Is there real free space now or will the cap
>>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>>> kernel).
>>>>>>
>>>>>> I will reappear with ONE_REG semantics.
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>>> again by "normal" developers. :)
>>>>
>>>> Before we did submodules and had a responsive BIOS maintainer, we 
>>>> maintained patches within qemu.git for our external dependencies.  I think 
>>>> that's a good strategy here too.  It's a little painful, but not entirely 
>>>> awful.
>>>>
>>>> At least it makes it possible for you to (hopefully) trivial rebase a 
>>>> patch if something is still in limbo.
>>>
>>> Yeah, that works. I can easily script that part. It doesn't solve the 
>>> actual underlying problem though that we don't know when the abi is 
>>> actually stable. I'm slowly starting to understand Pekka ;).
>>
>> IIRC, we never had this problem with qemu-kvm - as the merges were
>> coordinated with the kernel (subsystem) tree.
> 
> Are you suggesting that kvm header updates go through uq/master?  That seems 
> reasonable to me and is certainly the least amount of change.

Would be possible at least for changes that affect KVM bits. But we also
use that headers for virtio and vhost. VFIO will surely join that group.
So there is still coordination necessary.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]