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.
next prev parent 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: linkBe 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.