On Wed, Feb 27, 2008 at 12:55:52PM -0700, Alex Williamson wrote:
> Hi Simon,
> I'm not seeing how this doesn't break the x86 COMPAT/CONFIG_COMPAT
> code paths. Where does kexec_get_range_internal() get defined for
> COMPAT in [1/3], and where is machine_kexec_get_xen() defined for
> CONFIG_COMPAT in [2/3]? I'm fine with the ia64 parts if Ian/Keir want
> to check them into the main tree, but there is some mixed indenting in
> [3/3]. Thanks,
Thanks for pointing out the white-space issue, I'll fix that up asap.
As for the compat stuff...
The way that I understand the code is that basically
xen/common/kexec.c gets compiled twice using the following mechanism
at the very bottom of the file:
#if defined(CONFIG_COMPAT) && !defined(COMPAT)
Where xen/common/compat/kexec.c looks a bit like this:
So on the first stage of the run through xen/common/kexec.c, before
we get to #include "compat/kexec.c", any code that
is not protected by #ifdef COMPAT will be compiled.
If CONFIG_COMPAT isn't defined (elsewhere) then that is the
end and all is well.
If CONFIG_COMPAT is defined, then we enter the second stage,
where any code in "compat/kexec.c" not protected by #ifndef COMPAT
The important thing to note is that during this second stage,
all the code compiled in the first stage still exists.
kexec_get_range_internal() and all the functions that it calls
a) exist in xen/common/kexec.c and are compiled during the first stage,
that is, they are protected by #ifndef COMPAT.
b) present in other files that and are compiled independent
of any CONFIG_COMPAT games.
This means that kexec_get_range_internal(), and all the functions
that it relies on can be called by both non-compat version
of do_kexec_op(), which is compiled during the first stage,
and the compat version of do_kexec_op() (compat_kexec_op()).
The creation of the first version of do_kexec_op() is fairly obvious,
it is compiled as you would expect on a casual glance. This occurs
during stage one. The compilation of compat_kexec_op() is achieved
by "#define do_kexec_op compat_kexec_op" in xen/common/compat/kexec.c,
which essentially changes the function name for compilation in the
I'll come right out and say that I don't fancy this two stage .c
indirectly including itself approach. And I hope this change can help us
move away from there, as well as providing the functionality
extendability that this patch set describes.
As to the extent of testing this code. I have run it on ia64 and it
works. I have also compiled it on both i386 and x86_64. The latter
uses CONFIG_COMPAT by default, which is the configuration I tested.
Xen-devel mailing list