Proposed new directory layout for kvm and virtualization
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.]
Signature · 9 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
Quoted 14 lines
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
Quoted 2 lines
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.
ordrivers/kvm/* drivers/xen/* etc.
Christian?
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Quoted 16 lines · Christian Borntraeger
Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
Quoted 14 lines
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
Quoted 9 lines
Quoted 3 lines
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.
ordrivers/kvm/*drivers/xen/*etc.
There's already drivers/virtio/ for kvm. If kvm-specific drivers come up, we can place them in drivers/kvm/.
Signature · 9 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Quoted 6 lines · 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:
...
arch/*/kvm/arch dependent kvm code
Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
Quoted 10 lines · Heiko Carstens
Quoted 7 lines · 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:
...
arch/*/kvm/arch dependent kvm code
Quoted 3 lines
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.
Signature · 9 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Quoted 10 lines · Avi Kivity
Quoted 7 lines · Heiko Carstens
Quoted 2 lines · Avi Kivity
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.cis 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 <><
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Quoted 17 lines · Arnd Bergmann
Quoted 5 lines · Avi Kivity
Quoted 3 lines · Heiko Carstens
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
arch/*/kvm/arch dependent kvm codeMaybe
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.cis okay.
Quoted 9 lines
In that case, even
arch/*/{mm,kernel}/kvm.cwould 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 ofarch/*/{perfmon,crypto,xen,power}. Neither of these is particularly large, butarch/*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.
Signature · 9 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Quoted 1 line · Avi Kivity
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.
Quoted 9 lines · 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
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
Quoted 4 lines · Sam Ravnborg
Quoted 2 lines · 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:
Quoted 9 lines
Quoted 5 lines
virt/ top-level directory for hypervisors virt/kvm/ kvm common code virt/lguest/ the other hypervisor arch/*/kvm/ arch dependent kvm codeThe
arch/*/dirshall use same dir-name as used
in top-level directory.
Well, it isn't like that now (arch/x86/oprofile, etc.)
Quoted 6 lines
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?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 14 lines · Avi Kivity
Quoted 13 lines · Sam Ravnborg
Quoted 10 lines · 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
Quoted 5 lines
Quoted 3 lines
The
arch/*/dirshall 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.
Quoted 10 lines
Quoted 6 lines
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
Quoted 8 lines · Sam Ravnborg
Quoted 8 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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/.
Quoted 3 lines
Seems logical and fit the way we handle
mm/versusarch/*/mm,kernel/arch/*/kerneletc.
Exactly, so virt/kvm/ -> arch/x86/virt/kvm/.
Quoted 4 lines
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.
Signature · 9 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Quoted 9 lines · Avi Kivity
Quoted 3 lines
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 withvirt/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.
Signature · 2 lines
Hollis Blanchard IBM Linux Technology Center