Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2469207ybn; Thu, 26 Sep 2019 12:21:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDz0MdBBLcOwSCs8QlUBMG0r8x+AN36ADso/9sOga2A7ecfUuJSfTUh8zDJpXhlIHNYI61 X-Received: by 2002:aa7:d38e:: with SMTP id x14mr489041edq.102.1569525676896; Thu, 26 Sep 2019 12:21:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569525676; cv=none; d=google.com; s=arc-20160816; b=TPyRJO6s9+pxVIkxfVmWB705it3JKhs9q7yB4OofT38X3RZy2+mFPzvcn5kuGKV8gL uzUq26fnySAzWojWJpO4XrZ5DO4NJh2DjzcqNGcsdlMplELv5t62sM0MmxX5rKWk978s wN+gsCJQDgNDm6iFH/UylCb6vNu/FnnrAC/0IwJxu8Ceaf61d8fgb98WUwCvxqONJTPI Pt7+dJGDk5CkZbmyZ8xy5v1kgjZL8PiopAtw0LCb1qiQHiSCi24OZse5EigbdjFeLgqc UyiH99QphHAqbKcv2/b94sN+uKJ3F7h6R3UjTEiAkQWNaRSZ31y55LasGpwvRCwLayNH N7cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:dkim-filter; bh=AwASjrnLXi/qw8uPC6jnY4kcGOnTDEtI99vpaGYBJw4=; b=AcaVzjZLZYxpqwgZKdkjAoYX1xr1PReubY/ErXQveaYALYt05RbAt6bCHiLNJ3M1kh 80/OK9PNUyJgpcwMA67ilJc4wLgsR0nm0c4qz4473vfh7ipLumRXORoW3HGNFZ1pELo3 fC3k02E+4bD8x6PY/T226ZVJ3ts4j80Hj2CbkEZ2Y7XfaK2fzbQt7m821goc6Q9//Rpj dph9k+VKR9v+pwnfsGrb1Ub77G5xFq4NExbzVVNt/T+EH2uU5PrVr/QILI2IGQ3CLEjv BJbiQIjTlfsK7kdkZq1zZWBuHviyl/hYR13m2LUqIfeFjAv4P1mf8RGbB8TSRRqE6y// 1KBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@zytor.com header.s=2019091901 header.b=tIJN8Af3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si126499eda.300.2019.09.26.12.20.53; Thu, 26 Sep 2019 12:21:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@zytor.com header.s=2019091901 header.b=tIJN8Af3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728626AbfIZTS5 (ORCPT + 99 others); Thu, 26 Sep 2019 15:18:57 -0400 Received: from terminus.zytor.com ([198.137.202.136]:46741 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727707AbfIZTS4 (ORCPT ); Thu, 26 Sep 2019 15:18:56 -0400 Received: from [IPv6:2601:646:8600:3281:4da0:b184:256:e0c2] ([IPv6:2601:646:8600:3281:4da0:b184:256:e0c2]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id x8QJIhF53777727 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 Sep 2019 12:18:45 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com x8QJIhF53777727 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2019091901; t=1569525526; bh=AwASjrnLXi/qw8uPC6jnY4kcGOnTDEtI99vpaGYBJw4=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=tIJN8Af3E7QnjmLUz+OlO1AsKIFu0i9tVD2GgpHai0TmMJqQ1UYZNR/Pg5Ua+wr5e 0FX6M9Z+sycCegQPJI9JIalzTHVuM64ww2e0D0MQotYvPmb2tKfnirDkeqe7IuDyyw aG019c0Dl8W1DbbX6przkcHqgfw4xql5bzE3qwMHe8Rmd7WTZoQgxSsp6xnvKEKDiH k9Nm1ugztJWHYlblgjpBjKg80aSZ2eS9V3pSS2IwON49SvT/m0zE5p9b+yVcvJ7xyx 8Ezf0dDq5t7IbvcS3SngMwBwRYtShidPldENAEtLD859/rBFv/DROtFzU3Pf5mPDLt E0nnMeLbd+oKA== Date: Thu, 26 Sep 2019 12:18:36 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <20190926042116.17929-1-caoj.fnst@cn.fujitsu.com> <20190926060139.GA100481@gmail.com> <3073CD01-65C5-4BEC-B2FC-F76DD0E70D73@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc" To: Cao jin , Ingo Molnar 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 From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On September 26, 2019 1:20:02 AM PDT, Cao jin wrote: >On 9/26/19 3:58 PM, hpa@zytor=2Ecom wrote: >> On September 26, 2019 12:55:51 AM PDT, Cao jin > wrote: >>> On 9/26/19 2:01 PM, Ingo Molnar wrote: >>>> * Cao jin wrote: >>>> >>>>> The fields marked with (reloc) actually are not dedicated for >>> writing, >>>>> but communicating info for relocatable kernel with boot loaders=2E >For >>>>> example: >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> Field name: pref_address >>>>> Type: read (reloc) >>>>> Offset/size: 0x258/8 >>>>> Protocol: 2=2E10+ >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> Field name: code32_start >>>>> Type: modify (optional, reloc) >>>>> Offset/size: 0x214/4 >>>>> Protocol: 2=2E00+ >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> Signed-off-by: Cao jin >>>>> --- >>>>> Unless I have incorrect non-native understanding for "fill in", I >>> think >>>>> this is inaccurate=2E >>>>> >>>>> Documentation/x86/boot=2Erst | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/x86/boot=2Erst >b/Documentation/x86/boot=2Erst >>>>> index 08a2f100c0e6=2E=2Ea611bf04492d 100644 >>>>> --- a/Documentation/x86/boot=2Erst >>>>> +++ b/Documentation/x86/boot=2Erst >>>>> @@ -243,7 +243,7 @@ bootloader ("modify")=2E >>>>> =20 >>>>> All general purpose boot loaders should write the fields marked >>>>> (obligatory)=2E 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=2E >>>>> =20 >>>>> The byte order of all fields is littleendian (this is x86, after >>> all=2E) >>>> >>>> Well, this documentation is written from the point of view of a=20 >>>> *bootloader*, not the kernel=2E So the 'fill in' says that the >>> bootloader=20 >>>> 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=2E >>=20 >> Read means the boot later reads them=2E >>=20 > >Sorry I don't know what is going wrong in my mind=2E 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=2E 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=2E 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=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E