From: Marc Zyngier <marc.zyngier@arm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Scott Wood <scottwood@freescale.com>,
Christoffer Dall <c.dall@virtualopensystems.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH v5 01/12] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl
Date: Wed, 09 Jan 2013 16:12:02 +0000 [thread overview]
Message-ID: <50ED96D2.6010108@arm.com> (raw)
In-Reply-To: <54937915-46BE-4A50-B5AA-26940DEE6A92@suse.de>
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@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@linaro.org>
>>>> wrote:
>>>>> On 9 January 2013 14:58, Alexander Graf <agraf@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...
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2013-01-09 16:12 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 18:41 [PATCH v5 00/12] KVM/ARM vGIC support Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 01/12] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-08 22:36 ` Scott Wood
2013-01-08 23:17 ` Christoffer Dall
2013-01-08 23:29 ` Scott Wood
2013-01-08 23:49 ` Christoffer Dall
2013-01-09 0:12 ` Scott Wood
2013-01-09 10:02 ` Alexander Graf
2013-01-09 14:48 ` Peter Maydell
2013-01-09 14:58 ` Alexander Graf
2013-01-09 15:11 ` Peter Maydell
2013-01-09 15:17 ` Christoffer Dall
2013-01-09 15:20 ` Alexander Graf
2013-01-09 15:22 ` Marc Zyngier
2013-01-09 15:28 ` Alexander Graf
2013-01-09 15:50 ` Marc Zyngier
2013-01-09 15:56 ` Alexander Graf
2013-01-09 16:12 ` Marc Zyngier [this message]
2013-01-09 16:29 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 02/12] ARM: KVM: Keep track of currently running vcpus Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 03/12] ARM: gic: define GICH offsets for VGIC support Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code Christoffer Dall
2013-01-14 15:31 ` Will Deacon
2013-01-14 21:08 ` Christoffer Dall
2013-01-14 21:28 ` [kvmarm] " Alexander Graf
2013-01-14 22:50 ` Will Deacon
2013-01-15 10:33 ` Marc Zyngier
2013-01-08 18:41 ` [PATCH v5 05/12] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 06/12] ARM: KVM: VGIC distributor handling Christoffer Dall
2013-01-14 15:39 ` Will Deacon
2013-01-14 21:55 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 07/12] ARM: KVM: VGIC virtual CPU interface management Christoffer Dall
2013-01-14 15:42 ` Will Deacon
2013-01-14 22:02 ` Christoffer Dall
2013-01-15 11:00 ` Marc Zyngier
2013-01-15 14:31 ` Christoffer Dall
2013-01-16 15:29 ` Christoffer Dall
2013-01-16 16:09 ` Marc Zyngier
2013-01-16 16:13 ` Christoffer Dall
2013-01-16 16:17 ` [kvmarm] " Marc Zyngier
2013-01-08 18:42 ` [PATCH v5 08/12] ARM: KVM: vgic: retire queued, disabled interrupts Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 09/12] ARM: KVM: VGIC interrupt injection Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 10/12] ARM: KVM: VGIC control interface world switch Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 11/12] ARM: KVM: VGIC initialisation code Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 12/12] ARM: KVM: Add VGIC configuration option Christoffer Dall
2013-01-09 13:28 ` Sergei Shtylyov
2013-01-09 16:42 ` Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 1/2] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 2/2] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-09 16:48 ` [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Alexander Graf
2013-01-09 19:50 ` Scott Wood
2013-01-09 20:12 ` Alexander Graf
2013-01-09 21:15 ` Scott Wood
2013-01-09 21:37 ` Alexander Graf
2013-01-09 22:10 ` Scott Wood
2013-01-09 22:26 ` Christoffer Dall
2013-01-09 22:34 ` Alexander Graf
2013-01-10 11:15 ` Alexander Graf
2013-01-10 11:18 ` Gleb Natapov
2013-01-09 22:30 ` Alexander Graf
2013-01-10 10:17 ` Peter Maydell
2013-01-10 11:06 ` Alexander Graf
2013-01-10 11:53 ` Marc Zyngier
2013-01-10 11:57 ` Alexander Graf
2013-01-10 22:28 ` Marcelo Tosatti
2013-01-10 22:40 ` Scott Wood
2013-01-11 0:35 ` Marcelo Tosatti
2013-01-11 1:10 ` Scott Wood
2013-01-11 7:26 ` Christoffer Dall
2013-01-11 18:39 ` Marcelo Tosatti
2013-01-11 19:11 ` Alexander Graf
2013-01-11 19:18 ` Marcelo Tosatti
2013-01-11 19:33 ` Christoffer Dall
2013-01-11 15:42 ` Alexander Graf
2013-01-11 20:11 ` Scott Wood
2013-01-11 20:26 ` Alexander Graf
2013-01-11 19:17 ` Alexander Graf
2013-01-10 22:21 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50ED96D2.6010108@arm.com \
--to=marc.zyngier@arm.com \
--cc=agraf@suse.de \
--cc=c.dall@virtualopensystems.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=peter.maydell@linaro.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox