On 02/26/2011 04:57 PM, Eric W. Biederman wrote: >> >> I can't see any sane reason to *not* make kexec purgatory >> position-independent. It is the obvious thing to do. > > This isn't a case of the code not being position independent. This is > case of where the relocations are applied. > > I can see a couple of handling this with different tradeoffs. > > 1) We teach bootloaders how to load two kernels at once. This > completely avoids the purgatory, as it is replaced by code in the > bootloader that already exists to load the primary kernel and setup > it's arguments. > > 2) We add minimal relocation processing to purgatory, allowing us to do > the setup for the second kernel extremely early and allow it to be > compiled into the first kernel. > > 3) We come up with a scheme where we don't share code and the first > kernel copies the firmware information to place where the second > kernel can get at it, and uses it's own home grown stub and not > purgatory. > > I think this whole thing can be prototyped easily with a getting /sbin/kexec > to load to a fixed address and then baking that section into the primary > kernel. I'm not convinced that directly using /sbin/kexec is the right > way forward to handle the general case. This is something where the > devil is in the details. > OK... I'm clearly missing something... what code is not being position-independent and which code needs relocations applied? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
