Vivek Goyal <vgoyal at redhat.com> writes: > On Wed, Nov 21, 2012 at 11:50:56AM -0800, Yinghai Lu wrote: >> On Wed, Nov 21, 2012 at 6:50 AM, Vivek Goyal <vgoyal at redhat.com> wrote: >> > >> > So how do I force a 16bit or 32bit entry using a bzImage64? >> >> kexec -t bzImage -l .... >> will load low and use 32bit entry. >> >> kexec -t bzImage64 -l ... >> kexec -l ... >> will try to load high and use 64bit entry. > > Also bzImage64 is not really a new image format. It is just enhancement > of bzImage format. We keep on doing extention of bzImage and don't call it > a new image format. I am not sure how good an idea it is to export the > notion of new image type bzImage64 to user. For what the loader has to do bzImage64 is effectively a new format, and one way or another needs to be handled by separate functions so that the code remains readable. I asked YH to add the code that way because it means only a 64bit kexec has to carry that code and we don't have 64bit dependencies in in the 32bit build that will break. The code to prepare boot_params is still shared. Chaining to the 32bit loader if someone asks for --real-mode or perhaps --entry32 seems quite reasonable and only a couple of lines of code so I have not objections to that. While development is on-going forcing the image type seems very reasonable, but when the smoke clears I would like to see the bzImage64 format chaining to bzImage for the cases it does not handle. But with respect to autodetection only having bzImage64 kick in when loading a 64bit kernel is possible looks like the right way to go. Eric
