[PATCH v3 4/4] kexec, x86_64: Load bzImage64 above 4G

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux