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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
