[Xen-devel] Pre-OLS attempt for (xen)linux directory structure convergence

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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