From: Cao jin <caoj.fnst@cn.fujitsu.com>
To: <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <corbet@lwn.net>
Subject: Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"
Date: Fri, 27 Sep 2019 10:09:05 +0800 [thread overview]
Message-ID: <2595d3db-4149-5764-c265-62af273fb3e5@cn.fujitsu.com> (raw)
In-Reply-To: <A44CE024-DEB0-476C-B71B-883307952F10@zytor.com>
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
next prev parent reply other threads:[~2019-09-27 2:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 4:21 Cao jin
2019-09-26 6:01 ` Ingo Molnar
2019-09-26 6:03 ` hpa
2019-09-26 7:55 ` Cao jin
2019-09-26 7:58 ` hpa
2019-09-26 8:20 ` Cao jin
2019-09-26 19:18 ` hpa
2019-09-27 2:09 ` Cao jin [this message]
2019-09-26 15:20 ` Randy Dunlap
2019-09-26 19:17 ` hpa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2595d3db-4149-5764-c265-62af273fb3e5@cn.fujitsu.com \
--to=caoj.fnst@cn.fujitsu.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=hpa@zytor.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®