lkml.org 
[lkml]   [2012]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-11-22 22:01    [W:1.587 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site