Re: linux/arch/xen/i386 or linux/arch/i386/xen

[Zachary Amsden <zach@vmware.com>]

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