[Top][All Lists]
[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:32:16 +0100 |
On 11.01.2012, at 20:16, Jan Kiszka wrote:
> Hi,
>
> I'm a bit unhappy about the current state of our supposed to be
> automatically sync'ed linux-headers directory in qemu. It has been
> updated several times against undefined kernel trees, means against
> neither a released version nor kvm.git. Now, if I run an update against
> kvm.git + some local change, I get a churn of removals. Same will happen
> when that local change ever goes upstream before the other stuff got
> finally committed.
Yes, call me even more unhappy about it :(.
> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
> year ago but is not in any Linux release around. Fishy...
Ok, here's my workflow:
* KVM: receive patches on the ML
* KVM: wait for reviews, review myself
* KVM: send out a pull request
-- this is the point in time where I assume the ABI can be considered stable
--
* QEMU: run update on the headers, because in a perfect world things should
hit kvm.git any day
* KVM: pull request gets reviews causing not-pulls or abi changes and lots of
churn because i need forever to pullreq again ;)
I guess you see the problem. Hence I haven't pushed any kernel header updates
since I realized how badly broken that process was. However even the stuff
that's in qemu.git now hasn't managed to get upstream yet.
> 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.
Alex
- [Qemu-devel] State of KVM bits in linux-headers, Jan Kiszka, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers,
Alexander Graf <=
- Re: [Qemu-devel] State of KVM bits in linux-headers, Jan Kiszka, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers, Anthony Liguori, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers, Alexander Graf, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers, Jan Kiszka, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers, Anthony Liguori, 2012/01/11
- Re: [Qemu-devel] State of KVM bits in linux-headers, Alexander Graf, 2012/01/11