All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"gleb@redhat.com" <gleb@redhat.com>
Subject: Re: [RFC PATCH 1/2] ARM: KVM: move GIC/timer code to a common location
Date: Fri, 10 May 2013 09:46:29 +0100	[thread overview]
Message-ID: <518CB3E5.7090504@arm.com> (raw)
In-Reply-To: <518CABBB.7050909@redhat.com>

On 10/05/13 09:11, Paolo Bonzini wrote:
> Il 10/05/2013 09:23, Marc Zyngier ha scritto:
>>>> 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?
> 
> As I wrote in the other message, Linux in general has a shallow include/
> tree, so I think putting them in include/kvm/ is good.
> 
> Is there any precedent for naming stuff that is common to arm and
> aarch64?  

So far, we have:
- include/linux/irqchip/arm-gic.h
- include/clocksource/arm_arch_timer.h

So the trend seems to use "arm" as a prefix, and I will rename the files
to match this convention (which you actually suggested in your other email).

> I think to 99% of the world they will both be "arm", but of
> course the remaining 1% is likely over-represented among KVM-ARM
> maintainers. :)

Who? What? ;-)

Do you have any comment about patch 2/2? It is a bit more invasive, but
it is a cleanup in my opinion.

Thanks for the feedback,

	M.
-- 
Jazz is not dead. It just smells funny...


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:46:29 +0100	[thread overview]
Message-ID: <518CB3E5.7090504@arm.com> (raw)
In-Reply-To: <518CABBB.7050909@redhat.com>

On 10/05/13 09:11, Paolo Bonzini wrote:
> Il 10/05/2013 09:23, Marc Zyngier ha scritto:
>>>> 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?
> 
> As I wrote in the other message, Linux in general has a shallow include/
> tree, so I think putting them in include/kvm/ is good.
> 
> Is there any precedent for naming stuff that is common to arm and
> aarch64?  

So far, we have:
- include/linux/irqchip/arm-gic.h
- include/clocksource/arm_arch_timer.h

So the trend seems to use "arm" as a prefix, and I will rename the files
to match this convention (which you actually suggested in your other email).

> I think to 99% of the world they will both be "arm", but of
> course the remaining 1% is likely over-represented among KVM-ARM
> maintainers. :)

Who? What? ;-)

Do you have any comment about patch 2/2? It is a bit more invasive, but
it is a cleanup in my opinion.

Thanks for the feedback,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2013-05-10  8:46 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
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 [this message]
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=518CB3E5.7090504@arm.com \
    --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.