From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: State of KVM bits in linux-headers
Date: Wed, 11 Jan 2012 20:38:55 +0100 [thread overview]
Message-ID: <4F0DE54F.1050700@siemens.com> (raw)
In-Reply-To: <A89B3EE9-1CCD-4DBD-9459-6104F82B4A13@suse.de>
On 2012-01-11 20:32, Alexander Graf wrote:
>
> 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 ;)
Likely, the last item has to be moved up by two steps...
>
> 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.
On the other hand, if I recall correctly, there were some complaint on
the list recently about a header update patch again a Linux -rc version.
Because it removed the limbo land stuff in the same run, of course.
That's very bad. I see the problem: ppc targets will no longer build, at
least with KVM enabled, right? But this needs to be resolved now.
>
>> 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. :)
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-01-11 19:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 19:16 State of KVM bits in linux-headers Jan Kiszka
2012-01-11 19:32 ` Alexander Graf
2012-01-11 19:38 ` [Qemu-devel] " Anthony Liguori
2012-01-11 19:45 ` Alexander Graf
2012-01-11 19:46 ` Jan Kiszka
2012-01-11 19:48 ` Alexander Graf
2012-01-11 19:38 ` Jan Kiszka [this message]
2012-01-11 19:41 ` Anthony Liguori
2012-01-11 19:46 ` Alexander Graf
2012-01-11 19:48 ` Jan Kiszka
2012-01-11 19:52 ` Anthony Liguori
2012-01-11 19:53 ` Alexander Graf
2012-01-11 19:59 ` Anthony Liguori
2012-01-11 20:05 ` Alexander Graf
2012-01-11 20:16 ` Anthony Liguori
2012-01-11 21:48 ` Alexander Graf
2012-01-12 8:34 ` [Qemu-devel] " Avi Kivity
2012-01-11 19:56 ` Jan Kiszka
2012-01-12 6:35 ` Gleb Natapov
2012-01-11 19:32 ` [RFC][PATCH] Update linux headers against kvm.git Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0DE54F.1050700@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=agraf@suse.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox