Re: [GIT PULL] x86 fixes

[Matt Fleming]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/