On 11/22/2012 04:15 AM, Eric W. Biederman wrote: > > Let me be clear. kexec_ops as you have implemented it is absolutely > unacceptable. > > Your kexec_ops is not an abstraction but a hack that enshrines in stone > implementation details. > This is the kind of stuff that is absolutely endemic to the Xen endeavour, and which is why Xen is such a disease. The design principle seems to have been "hey, let's go and replace random Linux kernel internals with our own stuff, and make them ABIs, so that they can never change. Oh, and let's not bother documenting the constraints we're imposing, that might make the code manageable." I actually talked to Ian Jackson at LCE, and mentioned among other things the bogosity of requiring a PUD page for three-level paging in Linux -- a bogosity which has spread from Xen into native. It's a page wasted for no good reason, since it only contains 32 bytes worth of data, *inherently*. Furthermore, contrary to popular belief, it is *not* pa page table per se. Ian told me: "I didn't know we did that, and we shouldn't have to." Here we have suffered this overhead for at least six years, because *XEN FUCKED UP AND NOONE ELSE HAD ANY WAY OF KNOWING THAT*. Now we know that it can "maybe"(!!!) be fixed, if we are willing to spend time working on a dying platform, whereas we have already suffered the damage during the height of its importance. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
