This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Pre-OLS attempt for (xen)linux directory structure convergence
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Mon, 4 Jul 2005 18:45:17 -0700
Delivery-date: Tue, 05 Jul 2005 01:43:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWBAzHJ5mbAZ5XTSriDQv0ycWNWIw==
Thread-topic: 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

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!

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>