Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

["Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>]

The syscall ABI still has the wrong semantics.

Aka totally unmaintainable and umergeable.

The concept of domU support is also strange.  What does domU support even mean, 
when the dom0 support is loading a kernel to pick up Xen when Xen falls over.

I expect a lot of decisions about what code can be shared and what code can't 
is going to be driven by the simple question what does the syscall mean.

Sharing machine_kexec.c and relocate_kernel.S does not make much sense to me 
when what you are doing is effectively passing your arguments through to the 
Xen version of kexec.

Either Xen has it's own version of those routines or I expect the Xen version 
of kexec is buggy.   I can't imagine what sharing that code would mean.  By the 
same token I can't any need to duplicate the code either.

Furthermore since this is just passing data from one version of the syscall to 
another I expect you can share the majority of the code across all 
architectures that implement Xen.  The only part I can see being arch specific 
is the Xen syscall stub.

With respect to the proposed semantics of silently giving the kexec system call 
different meaning when running under Xen,
/sbin/kexec has to act somewhat differently when loading code into the Xen 
hypervisor so there is no point not making that explicit in the ABI.

Eric


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel