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: Alexander Graf
Subject: Re: [Qemu-devel] State of KVM bits in linux-headers
Date: Wed, 11 Jan 2012 20:53:31 +0100

On 11.01.2012, at 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.

So how about code that actually leverages the new headers?


Alex




reply via email to

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