[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1411456851.21380.355.camel@mfleming-mobl1.ger.corp.intel.com>
Date: Tue, 23 Sep 2014 08:20:51 +0100
From: Matt Fleming <matt.fleming@...el.com>
To: Ingo Molnar <mingo@...nel.org>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [GIT PULL] x86 fixes
On Tue, 2014-09-23 at 07:58 +0200, Ingo Molnar wrote:
>
> So if it's the GOT fixup then I feel the safest option is to
> revert 9cb0e394234d straight away, and then to do a functional
> revert of f23cf8bd5c1f49 as a separate step, perhaps via
> something really crude like:
>
> #include "../..../drivers/firmware/efi/libstub/efi-stub-helper.c"
>
> or so. (Maybe someone else can think of something
> cleaner/simpler, because this method is really ugly, as we'd have
> to #include the whole libstub library into eboot.c AFAICS...)
Yeah, I think at this point in the release cycle it would be safest to
revert back to the original scheme of #including the .c files. I'm not
sure if we can do any better in a robust way, i.e. without introducing
more regressions. Then take a look at doing the boot stub unification
with fresh eyes (and improved testing) after v3.17.
What I want to avoid is reverting the arm64 side of things too, so I'm
gonna take a stab at doing the necessary reverts/partial
reverts/whatever to get x86 back to the pre-merge window boot stub
duplicated code scheme.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists