It was conservative at the time the code was introduced and it most
definitely is not wrong. The code predates the verbage in boot.txt.
Apparently no one bothered to see what /sbin/kexec was actually doing
when they documented the 32bit boot loader interface. I was under the
impression that it was actual practice that was documented but in this
particular something else was documented instead. Since /sbin/kexec did
not need any of the more recent features we simply have not noticed it
until now.
We could work around it with a sentinel hack... except you *also*
probably modify *some* fields and now we have a horrid mix of
initialized and uninitialized fields to sort out... and there really
isn't any sane way for the kernel to sort that out.
We have a huge problem on our hands now because of it.
So, given the mess we now have on our hands... any suggestions how to best solve
it? There is the option of simply declaring old kexec binaries broken; they
will then not work reliably with newer kernels, if they even work reliably now
-- it is hard to know for certain.
I believe all added variables between the last version of the boot
protocol /sbin/kexec knows about and the current time were added in the
initialized data section. Certainly we can check and that will tell us
how likely changes in arch/x86/boot/ have been regressions in the 32bit
entry point support.
As for solving this there is a simple solution. Add a second jump
right after the first jump. The variables after the second jump can
all be zero initialized.
And if we really care about breaking other boot loaders we can take a
survey and actually look and see what they do. There really aren't that
many x86 boot loaders.