[RFC] Proposed new directory layout for kvm and virtualization

[RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

KVM is due to receive support for multiple architectures (ppc, ia64, and 
s390, in addition to the existing x86), hopefully in time for the 2.6.25 
merge window.  It is awkward to place the new arch support in 
drivers/kvm/, so I'd like to propose the following new layout:

  virt/         top-level directory for hypervisors
  virt/kvm/     kvm common code
  virt/lguest/  the other hypervisor
  arch/*/kvm/   arch dependent kvm code
  include/linux/kvm.h       arch independent interface
  include/asm/kvm.h         arch dependent interface
  include/linux/kvm_para.h  arch independent guest interface
  include/asm/kvm_para.h    arch dependent guest interface

The include/ hierarchy is already in place; I'm including it for 
completeness.

Comments, alternative suggestions welcome.

[This was foreshadowed about a year ago in 
http://lkml.org/lkml/2006/11/28/32, where the conclusion of the thread 
was to wait a year before making this change.  Quite an accurate 
prediction.]

-- 
error compiling committee.c: too many arguments to function

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Christian Borntraeger]

Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
> KVM is due to receive support for multiple architectures (ppc, ia64, and 
> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
> merge window.  It is awkward to place the new arch support in 
> drivers/kvm/, so I'd like to propose the following new layout:
> 
>   virt/         top-level directory for hypervisors
>   virt/kvm/     kvm common code
>   virt/lguest/  the other hypervisor
>   arch/*/kvm/   arch dependent kvm code
>   include/linux/kvm.h       arch independent interface
>   include/asm/kvm.h         arch dependent interface
>   include/linux/kvm_para.h  arch independent guest interface
>   include/asm/kvm_para.h    arch dependent guest interface
> 
> The include/ hierarchy is already in place; I'm including it for 
> completeness.

For completeness, where do we want to put the drivers?
drivers/*, drivers/net/* etc. 
or
drivers/kvm/* drivers/xen/* etc.

Christian?

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

Christian Borntraeger wrote:
> Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
>   
>> KVM is due to receive support for multiple architectures (ppc, ia64, and 
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
>> merge window.  It is awkward to place the new arch support in 
>> drivers/kvm/, so I'd like to propose the following new layout:
>>
>>   virt/         top-level directory for hypervisors
>>   virt/kvm/     kvm common code
>>   virt/lguest/  the other hypervisor
>>   arch/*/kvm/   arch dependent kvm code
>>   include/linux/kvm.h       arch independent interface
>>   include/asm/kvm.h         arch dependent interface
>>   include/linux/kvm_para.h  arch independent guest interface
>>   include/asm/kvm_para.h    arch dependent guest interface
>>
>> The include/ hierarchy is already in place; I'm including it for 
>> completeness.
>>     
>
> For completeness, where do we want to put the drivers?
> drivers/*, drivers/net/* etc. 
> or
> drivers/kvm/* drivers/xen/* etc.
>   

There's already drivers/virtio/ for kvm.  If kvm-specific drivers come 
up, we can place them in drivers/kvm/.

-- 
error compiling committee.c: too many arguments to function

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Heiko Carstens]

On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> KVM is due to receive support for multiple architectures (ppc, ia64, and 
> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
> merge window.  It is awkward to place the new arch support in drivers/kvm/, 
> so I'd like to propose the following new layout:
> ...
>  arch/*/kvm/   arch dependent kvm code

Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.

Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

Heiko Carstens wrote:
> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>   
>> KVM is due to receive support for multiple architectures (ppc, ia64, and 
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
>> merge window.  It is awkward to place the new arch support in drivers/kvm/, 
>> so I'd like to propose the following new layout:
>> ...
>>  arch/*/kvm/   arch dependent kvm code
>>     
>
> Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
>
>   

There will be several kvm files in that directory for x86. If you have 
just one file, I guess arch/*/virt/kvm.c is okay.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

[Arnd Bergmann]

On Tuesday 11 December 2007, Avi Kivity wrote:
> Heiko Carstens wrote:
> > On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> >
> >>  arch/*/kvm/   arch dependent kvm code
> >>     
> >
> > Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
> >
> There will be several kvm files in that directory for x86. If you have 
> just one file, I guess arch/*/virt/kvm.c is okay.

In that case, even arch/*/{mm,kernel}/kvm.c would work fine, as long as you
only want to support one hypervisor, or a small set of small files, there
is no need to have even have a virt directory.

However, if you want to have symmetry across the architectures, I think
arch/*/kvm/ works out best, along the lines of 
arch/*/{perfmon,crypto,xen,power}. Neither of these is particularly large,
but arch/* is typically not that crowded either.

	Arnd <><

Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

Arnd Bergmann wrote:
> On Tuesday 11 December 2007, Avi Kivity wrote:
>   
>> Heiko Carstens wrote:
>>     
>>> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>>>
>>>       
>>>>  arch/*/kvm/   arch dependent kvm code
>>>>     
>>>>         
>>> Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
>>>
>>>       
>> There will be several kvm files in that directory for x86. If you have 
>> just one file, I guess arch/*/virt/kvm.c is okay.
>>     
>
> In that case, even arch/*/{mm,kernel}/kvm.c would work fine, as long as you
> only want to support one hypervisor, or a small set of small files, there
> is no need to have even have a virt directory.
>
> However, if you want to have symmetry across the architectures, I think
> arch/*/kvm/ works out best, along the lines of 
> arch/*/{perfmon,crypto,xen,power}. Neither of these is particularly large,
> but arch/* is typically not that crowded either.
>   

In the case of x86, we'll have 16 arch dependent files (i8259.[ch], 
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch], 
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

[Carsten Otte]

Avi Kivity wrote:
> In the case of x86, we'll have 16 arch dependent files (i8259.[ch], 
> irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch], 
> x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a 
single file.

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Sam Ravnborg]

On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> KVM is due to receive support for multiple architectures (ppc, ia64, and 
> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
> merge window.  It is awkward to place the new arch support in 
> drivers/kvm/, so I'd like to propose the following new layout:
> 
>  virt/         top-level directory for hypervisors
>  virt/kvm/     kvm common code
>  virt/lguest/  the other hypervisor
>  arch/*/kvm/   arch dependent kvm code

The arch/*/dir shall use same dir-name as used
in top-level directory.
So use arch/*/virt/kvm/ if kvm really requires
a subdirectory of it own. Preferably not.
A handful of files named kvm* does not warrant their own
subdirectory IMO.

	Sam

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

Sam Ravnborg wrote:
> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>   
>> KVM is due to receive support for multiple architectures (ppc, ia64, and 
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25 
>> merge window.  It is awkward to place the new arch support in 
>> drivers/kvm/, so I'd like to propose the following new layout:
>>
>>  virt/         top-level directory for hypervisors
>>  virt/kvm/     kvm common code
>>  virt/lguest/  the other hypervisor
>>  arch/*/kvm/   arch dependent kvm code
>>     
>
> The arch/*/dir shall use same dir-name as used
> in top-level directory.
>   

Well, it isn't like that now (arch/x86/oprofile, etc.)

> So use arch/*/virt/kvm/ if kvm really requires
> a subdirectory of it own. Preferably not.
> A handful of files named kvm* does not warrant their own
> subdirectory IMO.
>
>   

We'll have 5-6 x86 specific files.

Where do you suggest we place them?


-- 
error compiling committee.c: too many arguments to function

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Sam Ravnborg]

On Tue, Dec 11, 2007 at 06:15:40PM +0200, Avi Kivity wrote:
> Sam Ravnborg wrote:
> >On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> >  
> >>KVM is due to receive support for multiple architectures (ppc, ia64, and 
> >>s390, in addition to the existing x86), hopefully in time for the 2.6.25 
> >>merge window.  It is awkward to place the new arch support in 
> >>drivers/kvm/, so I'd like to propose the following new layout:
> >>
> >> virt/         top-level directory for hypervisors
> >> virt/kvm/     kvm common code
> >> virt/lguest/  the other hypervisor
> >> arch/*/kvm/   arch dependent kvm code
> >>    
> >
> >The arch/*/dir shall use same dir-name as used
> >in top-level directory.
> >  
> 
> Well, it isn't like that now (arch/x86/oprofile, etc.)
oprofile is now the best leader to follow in this respect.
Just look at the utterly crap in their makefiles.

> >So use arch/*/virt/kvm/ if kvm really requires
> >a subdirectory of it own. Preferably not.
> >A handful of files named kvm* does not warrant their own
> >subdirectory IMO.
> >
> >  
> 
> We'll have 5-6 x86 specific files.
> 
> Where do you suggest we place them?
/arch/x86/virt/

Seems logical and fit the way we handle mm/ versus arch/*/mm,
kernel/ arch/*/kernel etc.

Are there any dependencies between the arch and non-arch files
such as they are combined in a single module?

	Sam

Re: [RFC] Proposed new directory layout for kvm and virtualization

[Avi Kivity]

Sam Ravnborg wrote:
>
>>> So use arch/*/virt/kvm/ if kvm really requires
>>> a subdirectory of it own. Preferably not.
>>> A handful of files named kvm* does not warrant their own
>>> subdirectory IMO.
>>>
>>>  
>>>       
>> We'll have 5-6 x86 specific files.
>>
>> Where do you suggest we place them?
>>     
> /arch/x86/virt/
>
>   

But, I want to place the arch independent files in virt/kvm/, so as to 
leave room for virt/lguest/.

> Seems logical and fit the way we handle mm/ versus arch/*/mm,
> kernel/ arch/*/kernel etc.
>   

Exactly, so virt/kvm/ -> arch/x86/virt/kvm/.

> Are there any dependencies between the arch and non-arch files
> such as they are combined in a single module?
>
>   

Yes, they are combined into a single module.

In the case of x86, some of arch/x86/... will be combined with virt/kvm/ 
to form kvm.ko, while others will generate kvm-intel.ko and kvm-amd.ko.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

[Hollis Blanchard]

On Tue, 2007-12-11 at 19:42 +0200, Avi Kivity wrote:
> 
> > Are there any dependencies between the arch and non-arch files
> > such as they are combined in a single module?  
> 
> Yes, they are combined into a single module.
> 
> In the case of x86, some of arch/x86/... will be combined with
> virt/kvm/ to form kvm.ko, while others will generate kvm-intel.ko and
> kvm-amd.ko.

Also, asm-offsets is a major sticking point. Either we create a
dependency on arch/*/kernel/asm-offsets.c, or we find a way to create a
new arch/*/virt/asm-offsets.c file.

-- 
Hollis Blanchard
IBM Linux Technology Center