On Wed, Jan 9, 2013 at 11:12 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 09/01/13 15:56, Alexander Graf wrote: >> >> On 09.01.2013, at 16:50, Marc Zyngier wrote: >> >>> On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf <agraf@xxxxxxx> wrote: >>>> On 09.01.2013, at 16:22, Marc Zyngier wrote: >>>> >>>>> On Wed, 9 Jan 2013 15:11:39 +0000, Peter Maydell >>>>> <peter.maydell@xxxxxxxxxx> >>>>> wrote: >>>>>> On 9 January 2013 14:58, Alexander Graf <agraf@xxxxxxx> 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. > > I really don't want to see that. Either we keep the API as it is, or we > change it for something that is really better and used by other > architectures. No point in turning it upside down if we're the only one > doing it. > > Oh, and as we're aiming for 3.9, it'd better be ready soon... > ok, I renamed it to KVM_ARM_SET_DEVICE_ADDR, using the same binary format, so user space tools remain compatible. I'll be happy to help out with a more generic API, once the kvm/arm patches reach upstream. Thanks so far! -Christoffer -- 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
