Re: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

[Vivek Goyal <vgoyal@in.ibm.com>]

On Wed, Feb 07, 2007 at 02:55:39PM +0000, Etienne Lorrain wrote:
> Vivek Goyal wrote:
> >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?
> 
>  Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
> cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
> different (like with virtual address at 0xC0000000) is Linux protected mode.
> Considering the linker used it is always the 4th program header, before there
> were only 3 program header,third one stay the NOTE one.
> 

Well this is all a lot of speculation. This is not standard way of retrieving
information from ELF. Number of program headers finally created keep on
changing. Previously it was left to the linker and now people have changed
it to 3 by specifically using PHDR directive.
  
> > Hence I think keeping real mode code out of vmlinux might prove to be a good idea.
> 
>  Well, ELF is a format made to describe what to load, at which addres, and I assume
> everyone recognise that some ELF section shall not be loaded, like the debug information.
> Gujin accepts having the real-mode treated like a program text and so in the program header,
> or like extra memory block with content like the symbol table used by a debugger, I do not
> know what is best so have implemented the two.
> 
> > 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.
> 
>  I did not touch the kernel entry point, the real mode entry point is at offset zero
> in the real-mode program header/section table.
> 
> > OTOH, now bzImage is relocatable. Is this image going to be relocatable?
> > How do we take care of that?
> 
>  Just I did not completely understand why you need relocation (and the announce
> was when I was in holidays far away). I know a simple kernel is needed to do
> some debugging when the main kernel has crashed, this kernel is better loaded
> at for instance 16 Mbytes. You probably do not want the same kernel as the main
> one because it may crash the same way, and you start a loop - and even then
> if you have exactly the same kernel it is easier to use the same write-protected
> block of memory with different data sections.
>  But I probably do not understand the problem so do not know what to write.
> 

As long as one can make sure that test kernel boots (commonly the case with
distros), same kernel can be used as capture kernel too. So the idea here
is to be able to use same kernel binary as production kernel and capture
kernel hence distros don't have to ship an additional kernel binary compiled
for a different physical addr just for dump capturing purposes.

Currently relocation information is extracted from vmlinux and packed in
final bzImage after some processing. After execution of real mode code
and once the image is decompressed, all the relocations are performed and
then control is transferred to kernel.

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/