x86: documentation fix regarding boot protocol
PATCH 1/1 x86: documentation fix regarding boot protocol
Documentation/x86/boot.txt describes payload_offset as the offset from the end of the real-mode code. In fact, it is more accurately described as the offset from the beginning of the protected-mode code, as (a) this is how it is actually calculated and (b) the padding after the real-mode code is not included in the offset.
---
Documentation/x86/boot.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
Documentation/x86/boot.txt +2 -2
@@ -537,8 +537,8 @@ Type: read Offset/size: 0x248/4 Protocol: 2.08+ - If non-zero then this field contains the offset from the end of the - real-mode code to the payload. + If non-zero then this field contains the offset from the beginning + of the protected-mode code to the payload. The payload may be compressed. The format of both the compressed and uncompressed data should be determined using the standard magic
Quoted 7 lines · Philipp Kohlbecher
Documentation/x86/boot.txtdescribespayload_offsetas the offset from the end of the real-mode code. In fact, it is more accurately described as the offset from the beginning of the protected-mode code, as (a) this is how it is actually calculated and (b) the padding after the real-mode code is not included in the offset.Signed-off-by Philipp Kohlbecher <[email protected]>
The padding after the real-mode code which you mention is just the implicit padding because the size of the real-mode code is specified in sectors (and hence is rounded up), isn't it?
Is it worth saying that the payload_offset is relative to (setup_sectors +1) * 512?
Quoted 22 lines
---
Documentation/x86/boot.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)Documentation/x86/boot.txt +2
-2@@ -537,8 +537,8 @@ Type: read Offset/size: 0x248/4 Protocol: 2.08+ - If non-zero then this field contains the offset from the end of the - real-mode code to the payload. + If non-zero then this field contains the offset from the beginning + of the protected-mode code to the payload. The payload may be compressed. The format of both the compressed and uncompressed data should be determined using the standard magic
Signature · 4 lines
Ian Campbell * weasel wonders how stupid one has to be to spam alt.anonymous.messages weasel: about half as stupid as one has to be to harvest it.
Quoted 7 lines · Ian Campbell
Quoted 6 lines · Philipp Kohlbecher
Documentation/x86/boot.txtdescribespayload_offsetas the offset from the end of the real-mode code. In fact, it is more accurately described as the offset from the beginning of the protected-mode code, as (a) this is how it is actually calculated and (b) the padding after the real-mode code is not included in the offset.
Quoted 7 lines
Quoted 1 line
Signed-off-by Philipp Kohlbecher <[email protected]>Acked-by Ian Campbell <[email protected]>The padding after the real-mode code which you mention is just the implicit padding because the size of the real-mode code is specified in sectors (and hence is rounded up), isn't it?
Yes, it is. You can certainly view the padding as an implicit part of the real-mode code, which is why the current statement isn't wrong -- there is simply room for improvement.
Quoted 2 lines
Is it worth saying that the
payload_offsetis relative to (setup_sectors+1) * 512?
The fact that the protected-mode code starts at that address is already mentioned under the heading "LOADING THE REST OF THE KERNEL" (where protected mode is for some reason referred to as "non-real-mode"). (Please note that the header field is called "setup_sects", not "setup_sectors".)
Quoted 21 lines
Quoted 21 lines
---
Documentation/x86/boot.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)Documentation/x86/boot.txt +2
-2@@ -537,8 +537,8 @@ Type: read Offset/size: 0x248/4 Protocol: 2.08+ - If non-zero then this field contains the offset from the end of the - real-mode code to the payload. + If non-zero then this field contains the offset from the beginning + of the protected-mode code to the payload. The payload may be compressed. The format of both the compressed and uncompressed data should be determined using the standard magic
Quoted 12 lines · Philipp Kohlbecher
Quoted 11 lines · Ian Campbell
Quoted 7 lines · Philipp Kohlbecher
Documentation/x86/boot.txtdescribespayload_offsetas the offset from the end of the real-mode code. In fact, it is more accurately described as the offset from the beginning of the protected-mode code, as (a) this is how it is actually calculated and (b) the padding after the real-mode code is not included in the offset.Signed-off-by Philipp Kohlbecher <[email protected]>Acked-by Ian Campbell <[email protected]>
Quoted 7 lines
Quoted 3 lines
The padding after the real-mode code which you mention is just the implicit padding because the size of the real-mode code is specified in sectors (and hence is rounded up), isn't it?
Yes, it is. You can certainly view the padding as an implicit part of the real-mode code, which is why the current statement isn't wrong -- there is simply room for improvement.
Agreed.
Quoted 6 lines
Quoted 2 lines
Is it worth saying that the
payload_offsetis relative to (setup_sectors+1) * 512?The fact that the protected-mode code starts at that address is already mentioned under the heading "LOADING THE REST OF THE KERNEL" (where protected mode is for some reason referred to as "non-real-mode").
I'd missed/forgotten that section, I don't think anything extra is needed then.
Ian.
Signature · 5 lines
Ian Campbell Current Noise: Orange Goblin - Made Of Rats Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux... (By [email protected], Christopher Browne)
Quoted 8 lines · Ian Campbell
The padding after the real-mode code which you mention is just the implicit padding because the size of the real-mode code is specified in sectors (and hence is rounded up), isn't it?
Is it worth saying that the
payload_offsetis relative to (setup_sectors+1) * 512?
Yes, the padding is considered part of the real mode code. The phrasing you're suggesting is probably the most unambiguous, though.
-hpa
Ingo Molnar
AppliedQuoted 6 lines · Philipp Kohlbecher
Documentation/x86/boot.txtdescribespayload_offsetas the offset from the end of the real-mode code. In fact, it is more accurately described as the offset from the beginning of the protected-mode code, as (a) this is how it is actually calculated and (b) the padding after the real-mode code is not included in the offset.
Quoted 6 lines
Signed-off-by Philipp Kohlbecher <[email protected]>---
Documentation/x86/boot.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
applied to tip/x86/doc, thanks!
Ingo