On 01/09/2013 03:37:20 PM, Alexander Graf wrote: > > > Am 09.01.2013 um 22:15 schrieb Scott Wood <scottwood@xxxxxxxxxxxxx>: > > > 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
