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 10:17:25 -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 17:17:01 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD542CE54@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: <516F50407E01324991DD6D07B0531AD542CE54@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@xxxxxx) wrote:
> > > So I'd vote for:
> > > 
> > > xen arch code in          arch/$(ARCH)/xen/
> > 
> > that's effectively sub-arch
> 
> The difference is admittedly very subtle (though probably
> not to some Linux kernel developer purists).  The question
> is whether xen is subsidiary architecture (which uses
> the mach- prefix) or whether it is functionality that can
> be turned on or off (no mach- prefix).

OK, how about one step at a time.  It's already a huge step to move
things around (between Kconfig, and tangled source, and headers...).
The advantage of move towards a known target (sub-arch) is there's
infrastructure in place to support it already.  I don't think it's a
dead-end to go there and then look towards the issues you brought up.

> And since this will appear hard-coded in include lines
> in source files, we do need to decide one way or the
> other.

Things move all the time, it's just a simple matter of patching ;-)
Or did I misunderstand you?

thanks,
-chris

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