"H. Peter Anvin" <hpa at zytor.com> writes: > On 02/26/2011 08:20 AM, Ahmed S. Darwish wrote: >> Hi, >> >> I'm continuing work on 'Saveoops', saving both early and normal Linux >> oops log to disk upon panic [*], using Kexec and bootloaders this time. >> >> Purgatory, the transitional mini-kernel used by kexec, is a relocatable >> ELF file. Userspace kexec-tools finds the final load address of such >> code (by parsing /proc/iomem, etc) and then applies the relocations >> itself before passing the now-ready executable image to kernel. >> >> Since capturing early oopses is the major goal, doing such relocation >> in userspace won't fit my purposes. Two options remain: >> - relocate purgatory entries in the kernel early boot path >> - or compile purgatory as position-independent, thus simplifying >> the kernel load logic >> >> The former will add extra logic in a sensitive path (early boot), while >> the latter will require changes inside the purgatory code itself, >> especially i386 assembly files. >> >> Any preferable option from our kexec and x86 maintainers? >> >> thanks! >> >> [*] http://news.gmane.org/find-root.php?message_id=<20110125134748.GA10051 at laptop> >> http://news.gmane.org/find-root.php?message_id=<20110126124954.GC24527 at laptop> >> > > 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. Eric
