All of lore.kernel.org
 help / color / mirror / Atom feed
From: scottwood@freescale.com (Scott Wood)
To: linux-arm-kernel@lists.infradead.org
Subject: [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
Date: Wed, 9 Jan 2013 16:10:38 -0600	[thread overview]
Message-ID: <1357769438.18196.5@snotra> (raw)
In-Reply-To: <4F8BA51C-1A21-4ED9-80CE-55ECB01C0AAD@suse.de> (from agraf@suse.de on Wed Jan  9 15:37:20 2013)

On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
> 
> 
> Am 09.01.2013 um 22:15 schrieb Scott Wood <scottwood@freescale.com>:
> 
> > I get that there's a tradeoff between getting something in now,  
> versus waiting until the API is more refined.  Tagging it with a  
> particular ISA seems like an odd way of saying "soon to be  
> deprecated", though.  What happens if we're still squabbling over the  
> perfect replacement API when we're trying to push PPC MPIC stuff in?
> 
> Then we're the ones who have to come up with a good interface.

How about another bad one, with PPC in the name, and some pleas to  
hurry things up? :-)

It's not as if there haven't been last-minute requests for API changes  
on the PPC side in the past...

> > Perhaps the threshold for an API becoming "permanent" should not be  
> acceptance into the tree, but rather the removal of an "experimental"  
> tag (including a way of shutting off experimental APIs to make sure  
> you're not depending on them).  Sort of like CONFIG_EXPERIMENTAL,  
> except actually used for its intended purpose (distributions should  
> have it *off* by default), and preferably managed at runtime.  Sort  
> of like drivers/staging, except for APIs rather than drivers.   
> Changes at that point should require more justification than before  
> merging, but would not have the strict compatibility requirement that  
> non-experimental APIs have.  This would make collaboration and  
> testing easier on APIs that aren't ready to be permanent.
> 
> This tag does exist. It's called "not in Linus' tree" :).

Which makes it a pain for multiple people to work on a new feature,  
especially when it spans components such as KVM and QEMU, and means  
that it gets less testing before the point of no return.

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Christoffer Dall <c.dall@virtualopensystems.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"<linux-arm-kernel@lists.infradead.org>"
	<linux-arm-kernel@lists.infradead.org>,
	"<kvmarm@lists.cs.columbia.edu>" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS
Date: Wed, 9 Jan 2013 16:10:38 -0600	[thread overview]
Message-ID: <1357769438.18196.5@snotra> (raw)
In-Reply-To: <4F8BA51C-1A21-4ED9-80CE-55ECB01C0AAD@suse.de> (from agraf@suse.de on Wed Jan  9 15:37:20 2013)

On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
> 
> 
> Am 09.01.2013 um 22:15 schrieb Scott Wood <scottwood@freescale.com>:
> 
> > I get that there's a tradeoff between getting something in now,  
> versus waiting until the API is more refined.  Tagging it with a  
> particular ISA seems like an odd way of saying "soon to be  
> deprecated", though.  What happens if we're still squabbling over the  
> perfect replacement API when we're trying to push PPC MPIC stuff in?
> 
> Then we're the ones who have to come up with a good interface.

How about another bad one, with PPC in the name, and some pleas to  
hurry things up? :-)

It's not as if there haven't been last-minute requests for API changes  
on the PPC side in the past...

> > Perhaps the threshold for an API becoming "permanent" should not be  
> acceptance into the tree, but rather the removal of an "experimental"  
> tag (including a way of shutting off experimental APIs to make sure  
> you're not depending on them).  Sort of like CONFIG_EXPERIMENTAL,  
> except actually used for its intended purpose (distributions should  
> have it *off* by default), and preferably managed at runtime.  Sort  
> of like drivers/staging, except for APIs rather than drivers.   
> Changes at that point should require more justification than before  
> merging, but would not have the strict compatibility requirement that  
> non-experimental APIs have.  This would make collaboration and  
> testing easier on APIs that aren't ready to be permanent.
> 
> This tag does exist. It's called "not in Linus' tree" :).

Which makes it a pain for multiple people to work on a new feature,  
especially when it spans components such as KVM and QEMU, and means  
that it gets less testing before the point of no return.

-Scott

  reply	other threads:[~2013-01-09 22:10 UTC|newest]

Thread overview: 158+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08 18:41 [PATCH v5 00/12] KVM/ARM vGIC support Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 01/12] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-08 18:41   ` Christoffer Dall
2013-01-08 22:36   ` Scott Wood
2013-01-08 22:36     ` Scott Wood
2013-01-08 23:17     ` Christoffer Dall
2013-01-08 23:17       ` Christoffer Dall
2013-01-08 23:29       ` Scott Wood
2013-01-08 23:29         ` Scott Wood
2013-01-08 23:49         ` Christoffer Dall
2013-01-08 23:49           ` Christoffer Dall
2013-01-09  0:12           ` Scott Wood
2013-01-09  0:12             ` Scott Wood
2013-01-09 10:02           ` Alexander Graf
2013-01-09 10:02             ` Alexander Graf
2013-01-09 14:48             ` Peter Maydell
2013-01-09 14:48               ` Peter Maydell
2013-01-09 14:58               ` Alexander Graf
2013-01-09 14:58                 ` Alexander Graf
2013-01-09 15:11                 ` Peter Maydell
2013-01-09 15:11                   ` Peter Maydell
2013-01-09 15:17                   ` Christoffer Dall
2013-01-09 15:17                     ` Christoffer Dall
2013-01-09 15:20                   ` Alexander Graf
2013-01-09 15:20                     ` Alexander Graf
2013-01-09 15:22                   ` Marc Zyngier
2013-01-09 15:22                     ` Marc Zyngier
2013-01-09 15:28                     ` Alexander Graf
2013-01-09 15:28                       ` Alexander Graf
2013-01-09 15:50                       ` Marc Zyngier
2013-01-09 15:50                         ` Marc Zyngier
2013-01-09 15:56                         ` Alexander Graf
2013-01-09 15:56                           ` Alexander Graf
2013-01-09 16:12                           ` Marc Zyngier
2013-01-09 16:12                             ` Marc Zyngier
2013-01-09 16:29                             ` Christoffer Dall
2013-01-09 16:29                               ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 02/12] ARM: KVM: Keep track of currently running vcpus Christoffer Dall
2013-01-08 18:41   ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 03/12] ARM: gic: define GICH offsets for VGIC support Christoffer Dall
2013-01-08 18:41   ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code Christoffer Dall
2013-01-08 18:41   ` Christoffer Dall
2013-01-14 15:31   ` Will Deacon
2013-01-14 15:31     ` Will Deacon
2013-01-14 21:08     ` Christoffer Dall
2013-01-14 21:08       ` Christoffer Dall
2013-01-14 21:28       ` [kvmarm] " Alexander Graf
2013-01-14 21:28         ` Alexander Graf
2013-01-14 22:50       ` Will Deacon
2013-01-14 22:50         ` Will Deacon
2013-01-15 10:33       ` Marc Zyngier
2013-01-15 10:33         ` Marc Zyngier
2013-01-08 18:41 ` [PATCH v5 05/12] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-08 18:41   ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 06/12] ARM: KVM: VGIC distributor handling Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-14 15:39   ` Will Deacon
2013-01-14 15:39     ` Will Deacon
2013-01-14 21:55     ` Christoffer Dall
2013-01-14 21:55       ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 07/12] ARM: KVM: VGIC virtual CPU interface management Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-14 15:42   ` Will Deacon
2013-01-14 15:42     ` Will Deacon
2013-01-14 22:02     ` Christoffer Dall
2013-01-14 22:02       ` Christoffer Dall
2013-01-15 11:00       ` Marc Zyngier
2013-01-15 11:00         ` Marc Zyngier
2013-01-15 14:31         ` Christoffer Dall
2013-01-15 14:31           ` Christoffer Dall
2013-01-16 15:29         ` Christoffer Dall
2013-01-16 15:29           ` Christoffer Dall
2013-01-16 16:09           ` Marc Zyngier
2013-01-16 16:09             ` Marc Zyngier
2013-01-16 16:13             ` Christoffer Dall
2013-01-16 16:13               ` Christoffer Dall
2013-01-16 16:17               ` [kvmarm] " Marc Zyngier
2013-01-16 16:17                 ` Marc Zyngier
2013-01-08 18:42 ` [PATCH v5 08/12] ARM: KVM: vgic: retire queued, disabled interrupts Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 09/12] ARM: KVM: VGIC interrupt injection Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 10/12] ARM: KVM: VGIC control interface world switch Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 11/12] ARM: KVM: VGIC initialisation code Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 12/12] ARM: KVM: Add VGIC configuration option Christoffer Dall
2013-01-08 18:42   ` Christoffer Dall
2013-01-09 13:28   ` Sergei Shtylyov
2013-01-09 13:28     ` Sergei Shtylyov
2013-01-09 16:42     ` Christoffer Dall
2013-01-09 16:42       ` Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Christoffer Dall
2013-01-09 16:26   ` Christoffer Dall
2013-01-09 16:26   ` [PATCH v5.1 1/2] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-09 16:26     ` Christoffer Dall
2013-01-09 16:26   ` [PATCH v5.1 2/2] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-09 16:26     ` Christoffer Dall
2013-01-09 16:48   ` [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Alexander Graf
2013-01-09 16:48     ` Alexander Graf
2013-01-09 19:50     ` Scott Wood
2013-01-09 19:50       ` Scott Wood
2013-01-09 20:12       ` Alexander Graf
2013-01-09 20:12         ` Alexander Graf
2013-01-09 21:15         ` Scott Wood
2013-01-09 21:15           ` Scott Wood
2013-01-09 21:37           ` Alexander Graf
2013-01-09 21:37             ` Alexander Graf
2013-01-09 22:10             ` Scott Wood [this message]
2013-01-09 22:10               ` Scott Wood
2013-01-09 22:26               ` Christoffer Dall
2013-01-09 22:26                 ` Christoffer Dall
2013-01-09 22:34                 ` Alexander Graf
2013-01-09 22:34                   ` Alexander Graf
2013-01-10 11:15                   ` Alexander Graf
2013-01-10 11:15                     ` Alexander Graf
2013-01-10 11:18                     ` Gleb Natapov
2013-01-10 11:18                       ` Gleb Natapov
2013-01-09 22:30               ` Alexander Graf
2013-01-09 22:30                 ` Alexander Graf
2013-01-10 10:17                 ` Peter Maydell
2013-01-10 10:17                   ` Peter Maydell
2013-01-10 11:06                   ` Alexander Graf
2013-01-10 11:06                     ` Alexander Graf
2013-01-10 11:53                   ` Marc Zyngier
2013-01-10 11:53                     ` Marc Zyngier
2013-01-10 11:57                     ` Alexander Graf
2013-01-10 11:57                       ` Alexander Graf
2013-01-10 22:28             ` Marcelo Tosatti
2013-01-10 22:28               ` Marcelo Tosatti
2013-01-10 22:40               ` Scott Wood
2013-01-10 22:40                 ` Scott Wood
2013-01-11  0:35                 ` Marcelo Tosatti
2013-01-11  0:35                   ` Marcelo Tosatti
2013-01-11  1:10                   ` Scott Wood
2013-01-11  1:10                     ` Scott Wood
2013-01-11  7:26                     ` Christoffer Dall
2013-01-11  7:26                       ` Christoffer Dall
2013-01-11 18:39                       ` Marcelo Tosatti
2013-01-11 18:39                         ` Marcelo Tosatti
2013-01-11 19:11                         ` Alexander Graf
2013-01-11 19:11                           ` Alexander Graf
2013-01-11 19:18                           ` Marcelo Tosatti
2013-01-11 19:18                             ` Marcelo Tosatti
2013-01-11 19:33                             ` Christoffer Dall
2013-01-11 19:33                               ` Christoffer Dall
2013-01-11 15:42                     ` Alexander Graf
2013-01-11 15:42                       ` Alexander Graf
2013-01-11 20:11                       ` Scott Wood
2013-01-11 20:11                         ` Scott Wood
2013-01-11 20:26                         ` Alexander Graf
2013-01-11 20:26                           ` Alexander Graf
2013-01-11 19:17               ` Alexander Graf
2013-01-11 19:17                 ` Alexander Graf
2013-01-10 22:21           ` Marcelo Tosatti
2013-01-10 22:21             ` 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=1357769438.18196.5@snotra \
    --to=scottwood@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.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.