On Tue, Feb 06, 2007 at 01:12:05PM +0000, Etienne Lorrain wrote: > > Building real mode code with kernel binary (vmlinux) has got another > > disadvantage that it breaks using vmlinux for kdump purposes. One compiles > > the kernel binary to execute from a different address but real mode > > code/data > > will continue to be at virtual/physical addr 0 and kexec can not load it > > as that physical memory is not available at all. Kdump skips the real mode > > code execution. > > But that is exactly what you want and need for kdump, isn't it? > The ELF file did not change, the program header has the last index at > address 0 that you do not want to load because you do not want to > execute the real-mode code. Load the rest and provide the 4 Kbytes > parameter page - it should work.
How do I know which program header is real mode code and the boot loader is not supposed to load it? May be PT_LOAD header with physical addr 0? What happens if changes happen and down the line we start compiling real mode code for non-zero address? Hence I think keeping real mode code out of vmlinux might prove to be a good idea. Secondly, if you compile real mode code with vmlinux, what would be the entry point for this ELF file? Real mode entry? Then I have not way to find out from ELF headers where is the protected mode entry point and I can not do use this vmlinux with kexec/kdump. OTOH, now bzImage is relocatable. Is this image going to be relocatable? How do we take care of that? Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
