WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] linux/arch/xen/i386 or linux/arch/i386/xen

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] linux/arch/xen/i386 or linux/arch/i386/xen
From: Chris Wright <chrisw@xxxxxxxx>
Date: Wed, 18 May 2005 09:47:48 -0700
Cc: Chris Wright <chrisw@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx>, Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxx>
Delivery-date: Wed, 18 May 2005 16:47:37 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD542CE25@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: <516F50407E01324991DD6D07B0531AD542CE25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@xxxxxx) wrote:
> Um, one other minor semantic issue.  The semantics of
> using mach-xxx may be inappropriate.  If my understanding
> is correct, two mach-xxx's cannot both be built, e.g. one
> cannot build a kernel which supports (for i386) both
> mach-es7000 and mach-voyager.

Yes, I had thought about this.  It's not clear to me it's problematic yet.
In many cases, it's exactly the bits that would become irrelevant that
are in the sub-arch (irq, smpboot, timers, etc.), whereas the generic
arch code would be sufficient running xenlinux on one of the sub-arches.

> There have been various discussions on this list about
> "transparent paravirtualization", i.e. the ability for
> a paravirtualized kernel to run both as a guest of Xen
> and on bare metal.  This is definitely an objective of
> Xen/ia64.  Nobody has tried it for Xen/x86, but if it
> can be done, I'm sure commercial companies and distros
> would be eager to utilize it (one less set of bits to
> support).

Hmm, this would be interesting/problematic.  Hadn't considered that
part.

> In many ways, a "xen" subdirectory is much more like
> a "pci" or "math-emu" subdirectory, than a subarch.
> For example, mach-es7000 and xen may need to co-exist
> in the same kernel.
> 
> So, mach-xen may be a poor choice.  A subtle distinction
> perhaps but when dealing with Linux kernel developers,
> purity of thinking may avoid future patch submission
> arguments.

The primary goal is to avoid code duplication to keep maintenance sane.
Clean way to do that is what really matters.

> So I'd vote for:
> 
> xen arch code in              arch/$(ARCH)/xen/

that's effectively sub-arch

> xen generic code in           drivers/xen/core/

yup (although no need for core/ subdir)

> xen arch includes in          include/asm-$(ARCH)/xen/

again, effectively sub-arch

> xen generic includes in               include/asm-xen/

or just include/xen

> though I realize this is not a democracy :-)

heh ;-)

thanks,
-chris

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

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