All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
Date: Sun, 15 Nov 2009 17:50:33 +0200	[thread overview]
Message-ID: <4B002349.5090309@redhat.com> (raw)
In-Reply-To: <4B002126.8020006@web.de>

On 11/15/2009 05:41 PM, Jan Kiszka wrote:
> Avi Kivity wrote:
>    
>> On 11/15/2009 05:02 PM, Jan Kiszka wrote:
>>      
>>> Where should I add "/* next version to use: 13 */", and who will take
>>> care that this comment will also be kept up to date? The CPU vmstate is
>>> already ordered according to logical groups, just look at earlier field.
>>> Only recent KVM additions happened to create some version ordering as
>>> well.
>>>
>>>        
>> Er, now I'm confused.  11 and 12 indeed do already exist, so how can you
>> update 11 retroactively?
>>      
> Oh, right, good that we discuss this. My patch dated back before the
> kvmclock addition, which IMHO incorrectly bumped the version numbers. I
> think the current policy in upstream is that we only increment once per
> qemu release, not per bit added.
>    

What about stable releases?  If we need to port a commit which adds a 
bit, we need to port the entire thing.

(well version numbers don't work with nonlinear development anyway).

>> Shouldn't you create 13 now?
>>      
> No, I rather think Glauber's 12 should be downgraded to 11 - unless it
> misses the qemu merge windows for 0.12. My extensions definitely target
> that release, thus will likely carry 11 in upstream. And we should
> really try to avoid diverging again.
>    

Agree.  Will commit the patches.

>> (and I meant: /* The above list is not sorted wrt version, watch out!
>> */, but now I feel I'm missing something).
>>
>>      
> Ok, can add such a note at the end.
>
>    

In upstream...

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2009-11-15 15:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12  0:04 [PATCH 1/2] qemu-kvm: x86: Refactor use of interrupt_bitmap Jan Kiszka
2009-11-12  0:05 ` [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states Jan Kiszka
2009-11-15 13:56   ` Avi Kivity
2009-11-15 14:21     ` Jan Kiszka
2009-11-15 14:27       ` Avi Kivity
2009-11-15 14:31         ` Jan Kiszka
2009-11-15 14:38           ` Avi Kivity
2009-11-15 15:02             ` Jan Kiszka
2009-11-15 15:10               ` Avi Kivity
2009-11-15 15:41                 ` Jan Kiszka
2009-11-15 15:50                   ` Avi Kivity [this message]
2009-11-24 14:15                     ` Avi Kivity
2009-11-24 22:08                   ` Marcelo Tosatti
2009-12-10 20:23                     ` Marcelo Tosatti

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=4B002349.5090309@redhat.com \
    --to=avi@redhat.com \
    --cc=glommer@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=quintela@redhat.com \
    /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.