On 09.01.2013, at 16:50, Marc Zyngier wrote: > On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf <ag...@suse.de> wrote: >> On 09.01.2013, at 16:22, Marc Zyngier wrote: >> >>> On Wed, 9 Jan 2013 15:11:39 +0000, Peter Maydell >>> <peter.mayd...@linaro.org> >>> wrote: >>>> On 9 January 2013 14:58, Alexander Graf <ag...@suse.de> wrote: >>>>> >>>>> Yeah, that was the basic idea. Considering that the patch set hasn't >>>>> been going >>>>> in for another 2 months after that discussion indicates that this > isn't >>>>> too much of >>>>> an issue though :). >>>> >>>> We might get there faster if people didn't keep nitpicking the APIs at >>> the >>>> last minute :-) >>> >>> Exactly. We're trying hard to get the damned thing merged, and the >>> permanent API churn quickly becomes a burden. >> >> As I said earlier, we have had a lot of experience in creating really > bad >> APIs in the past. > > Is this one really bad? Again, what changed in the meantime that makes you > think this API is wrong?
I complained about it 2 months ago already. >> But how about making this one specific? Call it > KVM_ARM_SET_VGIC_ADDRESS, >> keep the rest as it is, resend it, and later we can come up with an >> actually generic interface. > > Let's pretend you never wrote that, shall we? ;-) Why? The worst thing that happened to us so far were interfaces that looked generic and extensible and turned out not to be (see SET_SREGS in the ppc code). We have 2 options to circumvent this: 1) Commonly agree on an interface that actually is extensible and use it throughout the code 2) Create a very specific interface for a single use case, keep it implemented "forever" and as soon as we need more, implement a more generic one that goes back to 1 Since the ARM patches have been out of tree for too long, I'm happy with going route 2 until we go back to square 1. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
