lkml.org 
[lkml]   [2019]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"
From
Date
On 9/27/19 3:18 AM, hpa@zytor.com wrote:
> On September 26, 2019 1:20:02 AM PDT, Cao jin <caoj.fnst@cn.fujitsu.com> wrote:
>> On 9/26/19 3:58 PM, hpa@zytor.com wrote:
>>> On September 26, 2019 12:55:51 AM PDT, Cao jin
>> <caoj.fnst@cn.fujitsu.com> wrote:
>>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
>>>>> * Cao jin <caoj.fnst@cn.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@cn.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


\
 
 \ /
  Last update: 2019-09-27 04:09    [W:0.050 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site