[PATCH v5 01/12] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl

[Christoffer Dall]

On Wed, Jan 9, 2013 at 11:12 AM, Marc Zyngier <marc.zyngier at arm.com> 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 at 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.maydell at linaro.org>
>>>>> wrote:
>>>>>> On 9 January 2013 14:58, Alexander Graf <agraf at 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.
>
> 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