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

[Zachary Amsden <zach@xxxxxxxxxx>]

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