yhlu <[EMAIL PROTECTED]> writes: > On 11/4/06, Eric W. Biederman <[EMAIL PROTECTED]> 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 _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
