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

[Chris Wright <chrisw@xxxxxxxx>]

* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@xxxxxx) 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel