Xen devel - Jul 2005 - Pre-OLS attempt for (xen)linux directory structure convergence

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@lists.xensource.com
http://lists.xensource.com/xen-devel

* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@hp.com)
wrote:
> 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?)
That''s correct, no patches yet.  Post 2.6.12 merge makes most sense to
start w/ patches to me.
> 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.
Agreed.
> Here''s a strawman proposal:
Proposal below is essentially same as what came out of summit.
So, from quick look, I certainly agree ;-)
> 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]
except s/xen/mach-xen/
> linux/arch/*/xen/ - contains xen code that is archdep
and s/xen/mach-xen/
> 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
Also, since this means those headers are a snapshot, binary compatibility
needs to be (more) carefully considered.
> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > 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]
> 
> except s/xen/mach-xen/
> 
> > linux/arch/*/xen/ - contains xen code that is archdep
>
> and s/xen/mach-xen/
Doesn''t mach-xen imply (to a Linux kernel developer) that
xen is disjoint with and cannot co-exist with the other
mach-*?  Whereas leaving off the mach- implies that xen
more of a configurable option that may apply to multiple
mach- types?  (Or perhaps I am just thinking of "machvec"
on ia64?)

I guess I don''t care whether there is a mach- prefix or
not but want to ensure Linux conventions are kept where
possible.
 
> Also, since this means those headers are a snapshot, binary 
> compatibility
> needs to be (more) carefully considered.
Good point.  Perhaps we should specify VERSION macros like
Linux has (for both Linux and gcc)?

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel