Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"

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

 



On 9/27/19 3:18 AM, hpa@xxxxxxxxx wrote:
> On September 26, 2019 1:20:02 AM PDT, Cao jin <caoj.fnst@xxxxxxxxxxxxxx> wrote:
>> On 9/26/19 3:58 PM, hpa@xxxxxxxxx wrote:
>>> On September 26, 2019 12:55:51 AM PDT, Cao jin
>> <caoj.fnst@xxxxxxxxxxxxxx> wrote:
>>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
>>>>> * Cao jin <caoj.fnst@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
>>>>>> ---
>>>>>> 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





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux