[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.