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

Christoffer Dall c.dall at virtualopensystems.com
Wed Jan 9 11:29:31 EST 2013

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
>>>> 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!

More information about the linux-arm-kernel mailing list