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

Re: [Xen-devel] [PATCH v2 01/11] kexec: introduce kexec_ops struct



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.


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


 


Rackspace

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