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: Chris Wright <chrisw@xxxxxxxx>
Subject: Re: [Xen-devel] linux/arch/xen/i386 or linux/arch/i386/xen
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 18 May 2005 11:35:49 -0700
Cc: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx>, Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxx>
Delivery-date: Wed, 18 May 2005 18:36:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050518171725.GV27549@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>
References: <516F50407E01324991DD6D07B0531AD542CE54@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050518171725.GV27549@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Chris Wright wrote:

* 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.

Xen needs it's own mechanisms for implementing TLB flushes and other hardware type operations. Those operations are hardcoded in header files in the asm-i386 directory. It is just plain weird to have a completely separate set of functions and macros, say xen_local_save_flags(). Many of these macros and functions are used in common kernel code, and it would be rather taboo to #ifdef the kernel all over the place; #ifdef'ing the asm-i386 code for Xen support is also fairly ugly.

The mach-xen approach has the advantage that functions like this, local_save_flags can be moved into mach-default. Then if you build a Xen subarchitecture kernel, you can override any definitions you need by placing an alternative implementation in include/asm-i386/mach-xen - this system is already in place and works quite nicely.

If you've already got the sub-arch prefix, you also get your own arch/i386/mach-xen directory for xen specific support code for bootstrapping, reboot, shutdown, and a bunch of other platform type operations.

If you think about virtualization as a platform, classical virtualization is where the platform is a clone of a physical machine. Para-virtualization is where the platform presented to the operating system is shifted, but the underlying CPU/MMU hardware is the same. That is arguably exactly what sub-architecture support is supposed to provide.

Zach

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