[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2595d3db-4149-5764-c265-62af273fb3e5@cn.fujitsu.com>
Date: Fri, 27 Sep 2019 10:09:05 +0800
From: Cao jin <caoj.fnst@...fujitsu.com>
To: <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <tglx@...utronix.de>,
<mingo@...hat.com>, <bp@...en8.de>, <corbet@....net>
Subject: Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of
"reloc"
On 9/27/19 3:18 AM, hpa@...or.com wrote:
> On September 26, 2019 1:20:02 AM PDT, Cao jin <caoj.fnst@...fujitsu.com> wrote:
>> On 9/26/19 3:58 PM, hpa@...or.com wrote:
>>> On September 26, 2019 12:55:51 AM PDT, Cao jin
>> <caoj.fnst@...fujitsu.com> wrote:
>>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
>>>>> * Cao jin <caoj.fnst@...fujitsu.com> wrote:
>>>>>
>>>>>> The fields marked with (reloc) actually are not dedicated for
>>>> writing,
>>>>>> but communicating info for relocatable kernel with boot loaders.
>> For
>>>>>> example:
>>>>>>
>>>>>> ============ ============
>>>>>> Field name: pref_address
>>>>>> Type: read (reloc)
>>>>>> Offset/size: 0x258/8
>>>>>> Protocol: 2.10+
>>>>>> ============ ============
>>>>>>
>>>>>> ============ ========================
>>>>>> Field name: code32_start
>>>>>> Type: modify (optional, reloc)
>>>>>> Offset/size: 0x214/4
>>>>>> Protocol: 2.00+
>>>>>> ============ ========================
>>>>>>
>>>>>> Signed-off-by: Cao jin <caoj.fnst@...fujitsu.com>
>>>>>> ---
>>>>>> Unless I have incorrect non-native understanding for "fill in", I
>>>> think
>>>>>> this is inaccurate.
>>>>>>
>>>>>> Documentation/x86/boot.rst | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/x86/boot.rst
>> b/Documentation/x86/boot.rst
>>>>>> index 08a2f100c0e6..a611bf04492d 100644
>>>>>> --- a/Documentation/x86/boot.rst
>>>>>> +++ b/Documentation/x86/boot.rst
>>>>>> @@ -243,7 +243,7 @@ bootloader ("modify").
>>>>>>
>>>>>> All general purpose boot loaders should write the fields marked
>>>>>> (obligatory). Boot loaders who want to load the kernel at a
>>>>>> -nonstandard address should fill in the fields marked (reloc);
>> other
>>>>>> +nonstandard address should consult with the fields marked
>> (reloc);
>>>> other
>>>>>> boot loaders can ignore those fields.
>>>>>>
>>>>>> The byte order of all fields is littleendian (this is x86, after
>>>> all.)
>>>>>
>>>>> Well, this documentation is written from the point of view of a
>>>>> *bootloader*, not the kernel. So the 'fill in' says that the
>>>> bootloader
>>>>> should write those fields - which is correct, right?
>>>>>
>>>>
>>>> Take pref_address or relocatable_kernel for example, they have type:
>>>> read (reloc), does boot loader need to write them? I don't see grub
>>>> does
>>>> this at least.
>>>
>>> Read means the boot later reads them.
>>>
>>
>> Sorry I don't know what is going wrong in my mind. For me, if
>> pref_address has "read (reloc)", base on the current document, it means
>> boot loader will read it and also write it, which is conflicting. And
>> the purpose of pref_address should just inform boot loader that kernel
>> whats itself to be loaded at certain address, it don't want to be
>> written.
>
> read (reloc) means it is information for the boot loader to read, but that it can ignore it completely if it does not want to relocate the kernel.
>
so, "read (reloc)" also means boot loader can't write it, right?
Please bear my verbiage, see protocol explanation for "(reloc)":
"Boot loaders who want to load the kernel at a nonstandard address
should fill in the fields marked (reloc);"
Doesn't the explanation means: if boot loaders want to relocate the
kernel, they should write pref_address?
And while pref_address actually just provide a suggestion to boot
loader, loader could take it or not as you said, but won't write it.
That is why I choose the word "consult with" instead of "fill in".
--
Sincerely,
Cao jin
Powered by blists - more mailing lists