On Wed, Nov 15, 2006 at 08:48:41PM +0900, Magnus Damm wrote: > kexec-tools: Don't create hardcoded PT_LOAD header on old kernels (x86_64) > > This patch improves the kexec binary to avoid creating a PT_LOAD program > header > for the kernel if enough information cannot be gathered through /proc/kcore. > This to avoid avoid hardcoded values and the limitation of only supporting > 2MB > physical start address (kernel config option CONFIG_PHYSICAL_START). > > The patch also solves the kexec-tools-testing regression introduced by commit > 103c946e39eb9dd57ccbda20ac12ccb01f883c17 - with this patch it is now possible > to copy /proc/vmcore on 2.6.18. >
Hi Magnus, Thanks for the patch. My bad that I assumed that first kernel will be compiled for address 2MB and hardcoded it if one can not read /proc/kcore. I had few thoughts - You mentioned that in previous mail that you changed your compile address to 2MB and still problem was not resolved. That means problem should not be related to hardcoding the address to 2MB. Anyway if kernel is compiled for 2MB and user space is hardcoding it to 2MB then there is no incompatibility. Secondly, even if incompatibility was there I would have expected a trouble while opening the dump using gdb instead of while copying the vmcore. - I think this patch will break compatibility with gdb as we are not mapping kernel in virtual address space. All the physical chunks are being mapped to linearly mapped region in virtual address space and none is being mapped to kernel text virtual address region. I think there are two options to maintain backward compatibility with older kernels. a) we map 1MB to 40MB physical region in kernel text virtual address space instead of kernel linearly mapped region. b) we relax the elf note check in kexec-tools so that older kernels are not incompatible at all and /proc/kcore is readable. What I mean is that kexec-tools check for presense of a NULL being present in elf note name string. Instead of returning error there, we can print a warning that a null character is not present and continue processing kcore. This way older kernels will not require any special processing and ELF header creation logic will also be very neat. IMHO, we should go by the second option. What do you think? Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
