From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: linux/arch/xen/i386 or linux/arch/i386/xen Date: Wed, 18 May 2005 11:35:49 -0700 Message-ID: <428B8B05.1040708@vmware.com> References: <516F50407E01324991DD6D07B0531AD542CE54@cacexc12.americas.cpqcorp.net> <20050518171725.GV27549@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050518171725.GV27549@shell0.pdx.osdl.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Chris Wright Cc: "Magenheimer, Dan (HP Labs Fort Collins)" , xen-devel@lists.xensource.com, Mark Williamson , Vincent Hanquez List-Id: xen-devel@lists.xenproject.org Chris Wright wrote: >* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@hp.com) 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