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


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

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Pre-OLS attempt for (xen)linux directory structure convergence
From: Chris Wright <chrisw@xxxxxxxx>
Date: Mon, 4 Jul 2005 19:09:35 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Jul 2005 02:08:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD54FA3A5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <516F50407E01324991DD6D07B0531AD54FA3A5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
* 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.


> 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

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