From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Date: Wed, 9 Jan 2013 16:10:38 -0600 Message-ID: <1357769438.18196.5@snotra> References: <4F8BA51C-1A21-4ED9-80CE-55ECB01C0AAD@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Christoffer Dall , "kvm@vger.kernel.org list" , "" , "" To: Alexander Graf Return-path: Received: from ch1ehsobe002.messaging.microsoft.com ([216.32.181.182]:17047 "EHLO ch1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199Ab3AIWKq convert rfc822-to-8bit (ORCPT ); Wed, 9 Jan 2013 17:10:46 -0500 In-Reply-To: <4F8BA51C-1A21-4ED9-80CE-55ECB01C0AAD@suse.de> (from agraf@suse.de on Wed Jan 9 15:37:20 2013) Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On 01/09/2013 03:37:20 PM, Alexander Graf wrote: > > > Am 09.01.2013 um 22:15 schrieb Scott Wood : > > > 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