On 11/5/06, Eric W. Biederman ebiederm@xmission.com wrote:
First a decode of letters, in bzImage the b stands for big and the z stands for gzip. We don't have a bzip2 decompressor in there.
Thanks for the explanation...
An interesting question is if we make a bImage target that does everything except the decompression (because nothing would be compressed) would that suit your needs?
That could be good for us.
Hacks like that are a support pain. I don't have a problem with weird magic compatibility glue in the bzImage format but I don't want to introduce another one.
But it seems that current boot loader only use first program header's p_addr?
At least before we jump to the 64bit elf. For size the 32bit kernel should be smaller, so I don't understand the interest in the 64bit kernel at this point. If we do the 32/64bit transition at the last moment like etherboot does this requires about 100-200 extra lines of code.
that 256 byte code could be done in elfboot, or head.s of mkelfImage. A: elfboot (not 64bit aware) ---> 32bit elf --->64 bit kernel (head.S startup_32 then startup_64) B: elfboot (not 64bit aware) ---> 32bit elf ( elf do the 32->64 transition) --->64 bit kernel (startup_64) C: elfboot (64bit aware, switch to 64bit) ---> 64bit elf --->64 bit kernel (startup_64)
the A is less work in all.
the reason for using 64bit kernel: 1. don't want to dig i386 arch together with final x86_64 2. for 64bit resource support, the 32bit kernel will ignore or clear that resource.
YH