All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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: [Qemu-devel] 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

  parent reply	other threads:[~2012-01-11 19:39 UTC|newest]

Thread overview: 34+ 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:16 ` [Qemu-devel] " Jan Kiszka
2012-01-11 19:32 ` Alexander Graf
2012-01-11 19:32   ` [Qemu-devel] " Alexander Graf
2012-01-11 19:38   ` Anthony Liguori
2012-01-11 19:45     ` Alexander Graf
2012-01-11 19:46     ` Jan Kiszka
2012-01-11 19:46       ` Jan Kiszka
2012-01-11 19:48       ` Alexander Graf
2012-01-11 19:48         ` Alexander Graf
2012-01-11 19:38   ` Jan Kiszka [this message]
2012-01-11 19:38     ` Jan Kiszka
2012-01-11 19:41     ` Anthony Liguori
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:48           ` Jan Kiszka
2012-01-11 19:52           ` Anthony Liguori
2012-01-11 19:52             ` Anthony Liguori
2012-01-11 19:53             ` Alexander Graf
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-11 21:48                       ` [Qemu-devel] " Alexander Graf
2012-01-12  8:34                       ` Avi Kivity
2012-01-12  8:34                         ` Avi Kivity
2012-01-11 19:56             ` Jan Kiszka
2012-01-11 19:56               ` Jan Kiszka
2012-01-12  6:35         ` Gleb Natapov
2012-01-12  6:35           ` Gleb Natapov
2012-01-11 19:32 ` [RFC][PATCH] Update linux headers against kvm.git Jan Kiszka
2012-01-11 19:32   ` [Qemu-devel] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.