Re: [RFC] KVM Source layout Proposal to accommodate new CPU architecture

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.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/