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