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

[Alexander Graf]

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