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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
