From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC] KVM Source layout Proposal to accommodate new CPU architecture Date: Tue, 02 Oct 2007 16:29:36 +1000 Message-ID: <1191306576.6979.91.camel@localhost.localdomain> References: <42DFA526FC41B1429CE7279EF83C6BDC753A4E@pdsmsx415.ccr.corp.intel.com> <46FB7566.9030504@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC753E73@pdsmsx415.ccr.corp.intel.com> <46FD1392.1080905@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC754031@pdsmsx415.ccr.corp.intel.com> <46FD33F2.9090506@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC754076@pdsmsx415.ccr.corp.intel.com> <46FF7FF6.6090103@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC75421C@pdsmsx415.ccr.corp.intel.com> <46FFAB00.4050103@qumranet.com> <1191298279.6979.50.camel@localhost.localdomain> <1191304874.1152.10.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Hollis Blanchard Return-path: In-Reply-To: <1191304874.1152.10.camel@basalt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Tue, 2007-10-02 at 01:01 -0500, Hollis Blanchard wrote: > On Tue, 2007-10-02 at 14:11 +1000, Rusty Russell wrote: > > On Tue, 2007-10-02 at 01:19 +0000, Hollis Blanchard wrote: > > > On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: > > > > > > > > Eventually I'd like to see the code in arch/*/kvm. That's probably not > > > > easily doable right now because modules cannot span directories, but > > > > once that's solved, we'll do that as this is most consistent with the > > > > rest of the kernel. > > > > > > What is the "spanning directories" issue? Can't I build > > > arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe > > > sort out the dependency? > > > > Sure, but it creates a silly module. > > Isn't there precedent in other areas? What about cpufreq or ALSA? (I'm > really asking; don't have time to investigate further right now.) Hmm, cpufreq does do something like this, so I guess it's a fair call. > > I think guest code belongs in arch/*/kvm/, but host code can be done as > > subdirs under drivers/kvm/. > > Funny, I would say the opposite. The host code is where I'm mucking with > deep architectural state like stealing the TLB out from under Linux. The > guest state is all "what would a processor like this do?" >>From my POV all platforms belong in arch/*/, and KVM just presents another platform. But the implementation of KVM is as much kvm-specific as arch-specific, so I can argue over that one. Whatever way we go, grouping both host and guest support in the same dir seems confusing (which is why lguest is moving to arch/i386/lguest/ for guest and drivers/lguest/i386/ for host). Cheers, Rusty. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/