All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <cdall@cs.columbia.edu>
Cc: <catalin.marinas@arm.com>, <kvmarm@lists.cs.columbia.edu>,
	<linux-arm-kernel@lists.infradead.org>, <kvm@vger.kernel.org>,
	<gleb@redhat.com>, <pbonzini@redhat.com>
Subject: Re: [RFC PATCH 1/2] ARM: KVM: move GIC/timer code to a common location
Date: Fri, 10 May 2013 09:23:56 +0200	[thread overview]
Message-ID: <f816c184d2512dad242b383deac7453e@localhost> (raw)
In-Reply-To: <20130509181101.GA17253@gmail.com>

On Thu, 9 May 2013 11:11:01 -0700, Christoffer Dall
<cdall@cs.columbia.edu>
wrote:
> On Fri, May 03, 2013 at 03:02:52PM +0100, Marc Zyngier wrote:
>> As KVM/arm64 is looming on the horizon, it makes sense to move some
>> of the common code to a single location in order to reduce duplication.
>> 
>> The code could live anywhere. Actually, most of KVM is already built
>> with a bunch of ugly ../../.. hacks in the various Makefiles, so we're
>> not exactly talking about style here. But maybe it is time to start
>> moving into a less ugly direction.
>> 
>> The include files must be in a "public" location, as they are accessed
>> from non-KVM files (arch/arm/kernel/asm-offsets.c).
>> 
>> For this purpose, introduce two new locations:
>> - virt/kvm/arm/ : x86 and ia64 already share the ioapic code in
>>   virt/kvm, so this could be seen as a (very ugly) precedent.
>> - include/kvm/  : there is already an include/xen, and while the
>>   intent is slightly different, this seems as good a location as
>>   any
> 
> This overall looks ok, just a few points:
> 
> 1. Should we have a namespace per arch in the include directory, as in
>    include/kvm/arm?

So I thought of that at one point, but discarded the idea because it seems
to convey the wrong message:
We're moving the include files because they are architecture independent,
and referring to an architecture name in the path feels a bit odd. Or maybe
arm-common?

I don't have strong feelings about it though...

> 2. We could drop the kvm_ prefix from the include files now

Agreed.

It would be interesting to see what the KVM maintainers think of all this.
Gleb? Paolo?

        M.
-- 
Fast, cheap, reliable. Pick two.

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/2] ARM: KVM: move GIC/timer code to a common location
Date: Fri, 10 May 2013 09:23:56 +0200	[thread overview]
Message-ID: <f816c184d2512dad242b383deac7453e@localhost> (raw)
In-Reply-To: <20130509181101.GA17253@gmail.com>

On Thu, 9 May 2013 11:11:01 -0700, Christoffer Dall
<cdall@cs.columbia.edu>
wrote:
> On Fri, May 03, 2013 at 03:02:52PM +0100, Marc Zyngier wrote:
>> As KVM/arm64 is looming on the horizon, it makes sense to move some
>> of the common code to a single location in order to reduce duplication.
>> 
>> The code could live anywhere. Actually, most of KVM is already built
>> with a bunch of ugly ../../.. hacks in the various Makefiles, so we're
>> not exactly talking about style here. But maybe it is time to start
>> moving into a less ugly direction.
>> 
>> The include files must be in a "public" location, as they are accessed
>> from non-KVM files (arch/arm/kernel/asm-offsets.c).
>> 
>> For this purpose, introduce two new locations:
>> - virt/kvm/arm/ : x86 and ia64 already share the ioapic code in
>>   virt/kvm, so this could be seen as a (very ugly) precedent.
>> - include/kvm/  : there is already an include/xen, and while the
>>   intent is slightly different, this seems as good a location as
>>   any
> 
> This overall looks ok, just a few points:
> 
> 1. Should we have a namespace per arch in the include directory, as in
>    include/kvm/arm?

So I thought of that at one point, but discarded the idea because it seems
to convey the wrong message:
We're moving the include files because they are architecture independent,
and referring to an architecture name in the path feels a bit odd. Or maybe
arm-common?

I don't have strong feelings about it though...

> 2. We could drop the kvm_ prefix from the include files now

Agreed.

It would be interesting to see what the KVM maintainers think of all this.
Gleb? Paolo?

        M.
-- 
Fast, cheap, reliable. Pick two.

  reply	other threads:[~2013-05-10  7:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 14:02 [RFC PATCH 0/2] ARM: KVM: Moving GIC/timer out of arch/arm Marc Zyngier
2013-05-03 14:02 ` Marc Zyngier
2013-05-03 14:02 ` [RFC PATCH 1/2] ARM: KVM: move GIC/timer code to a common location Marc Zyngier
2013-05-03 14:02   ` Marc Zyngier
2013-05-09 18:11   ` Christoffer Dall
2013-05-09 18:11     ` Christoffer Dall
2013-05-10  7:23     ` Marc Zyngier [this message]
2013-05-10  7:23       ` Marc Zyngier
2013-05-10  8:09       ` Paolo Bonzini
2013-05-10  8:09         ` Paolo Bonzini
2013-05-10  8:11       ` Paolo Bonzini
2013-05-10  8:11         ` Paolo Bonzini
2013-05-10  8:46         ` Marc Zyngier
2013-05-10  8:46           ` Marc Zyngier
2013-05-03 14:02 ` [RFC PATCH 2/2] ARM: KVM: standalone Makefile for vgic and timers Marc Zyngier
2013-05-03 14:02   ` Marc Zyngier
2013-05-10  9:39   ` Paolo Bonzini
2013-05-10  9:39     ` Paolo Bonzini
2013-05-10  9:59     ` Marc Zyngier
2013-05-10  9:59       ` Marc Zyngier
2013-05-03 15:31 ` [RFC PATCH 0/2] ARM: KVM: Moving GIC/timer out of arch/arm Anup Patel
2013-05-03 15:31   ` Anup Patel
2013-05-03 15:55   ` Marc Zyngier
2013-05-03 15:55     ` Marc Zyngier
2013-05-12  9:03     ` Gleb Natapov
2013-05-12  9:03       ` Gleb Natapov
2013-05-12 10:23       ` Catalin Marinas
2013-05-12 10:23         ` Catalin Marinas

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=f816c184d2512dad242b383deac7453e@localhost \
    --to=marc.zyngier@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@cs.columbia.edu \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.