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

[Alexander Graf]

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.


Alex