yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
1M for bzImage remains fine. All bootloaders would break if you changed that. But for vmlinux you pretty much have it nailed.
Actually, we only mkelfImage with bzImage before we are trying to use lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can get 5% more space than bz2.
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.
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?
I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. then we don't need to switch from 32bit mode to 64 bit mode in head.s of mkelfImage. and still convert 64elf to 32bit elf. Also it would make other 32 bit bootloader still can load vmlinux64. Then we only need to make sure head.s of mkelfImage can get correct entry_point.
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.
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
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.
Eric