A couple months ago, there was a thread discussing various
opinions for directory structures for including xenlinux code
into the Linux tree. (The current structure is not architecture
independent and also uses some names/terminology that might
need to change to be more acceptable to Linux kernel
developers.)
I think Chris Wright said at the time that he would be
working on a patch to restructure the existing xenlinux
tree in xenbits, but I don't think this patch has been
submitted. (Correct, Chris?)
With OLS (Ottawa Linux Symposium) coming up rapidly, I want
to resurrect this discussion. If we can converge on
a solution via email , OLS will be a good forum where we can
work together to lobby the Linux kernel developers. And if
we can't converge before OLS, we can have a BOF at the
mini-summit to see if we (Xen developers) can converge.
I propose that the best chance of success is to look at
the directory structure strictly from a Linux point-of-view,
even if it causes some restructuring in the xenbits tree
and some annoying changes to current include lines.
Here's a strawman proposal:
linux/include/xen/ - contains all xen includes that
 are common (not archdep)
linux/include/asm-*/xen/ - contains all xen includes
 required for a specific architecture[1]
linux/arch/*/xen/ - contains xen code that is archdep
linux/drivers/xen/core/ - contains xen code that
 is common to all xen architectures, but is not
 specific to a particular driver class
linux/drivers/xen/{blkback,...}/ - contains xen code
 that is (or soon will be) common for specific drivers
CONFIG_XEN is used in config/Makefiles/code.
CONFIG_XEN_arch (e.g. CONFIG_XEN_X86) is used (only
 if absolutely necessary) in xen common code to
 indicate code that is archdep
[1] this includes header files containing macros/inlines
 to "arch-dep'ify" code in linux/drivers/xen; these
 header files do not exist today because all drivers
 are x86-specific.
Of particular note in this proposal:
1) There is NO linux/arch/xen or linux/include/asm-xen. These
 directory names imply that xen is an architecture, whereas
 it actually encompasses several architectures.
2) There is NO linux/.../*public/ for xen. The term
 "public" makes sense from Xen's point-of-view but
 is confusing from a Linux point-of-view. Also, the
 files such as public/arch-x86.h would be moved to
 the appropriate include/asm-*/xen directory
3) There is no place to put cross-arch Xen-specific code
 that is not related to drivers. (Is there any?)
4) CONFIG_XEN should *not* eliminate the possibility of
 transparent paravirtualization, which works today
 on Linux/ia64.
Commence firing!
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel