sentence needs to be improved

[PinoTsao]

In "Kernel booting process. Part 4.", section "Reload the segments if needed", one sentence should be improved:

The value assigned to it is an offset relative to the offset of the segment

==>

The value assigned to it is an offset relative to the segment

[tkyymmt]

Would you mind sending PR?

[PinoTsao]

yes, but I need to learn how to sending a PR, please wait for a while:)

[PinoTsao]

And I want to send PR after finish reading "Kernel booting process. Part 4.", because there maybe other description need to be improved, I will leave a post for each one in this discussion thread. For example, I see this also needs improvement:

When we are using position-independent code an address is obtained by adding the address field of the instruction and the value of the program counter

==>

When we are using position-independent code, an address is obtained by adding the address field of the instruction to the value of the program counter

[PinoTsao]

After comparison of the LOAD_PHYSICAL_ADDR and value of the ebx register, we add the offset from the startup_32 where to decompress the compressed kernel image. If the CONFIG_RELOCATABLE option is not enabled during kernel configuration, we just put the default address where to load kernel and add z_extract_offset to it.

To be honest, I think most content of it is wrong, for example, I don't see any reference of z_extract_offset in current code here, maybe in older time it is different.

It is just a calculation of physical address where to place the decompressed kernel, if we don't have CONFIG_RELOCATABLE, it is the LOAD_PHYSICAL_ADDR, or else, it will be the address of %ebp(protect mode kernel loaded address) aligned to BP_kernel_alignment, while no less than LOAD_PHYSICAL_ADDR.

[PinoTsao]

The compressed kernel image should be moved to the end of the decompression buffer to simplify calculations where kernel will be located later. For this:

Although there is no obvious buffer ending address in the code, but I feel "moved against to the end xxx" is more accurate, "against" has more meaning that the compressed kernel wouldn't exceed the buffer. And I don't quite understand why the latter part exists, how about:

The compressed kernel image will be moved against the end of the decompression buffer for safety in-place decompression.

[PinoTsao]

Next we subtract address of the _end symbol from this value and add the result of subtraction to ebx register which will stores base address for kernel decompression.

the ending words is confusing, how about:

Next we subtract address of the _end symbol(which also is the size of compressed kernel) from this value, and add the result of subtraction to ebx register which will stores the address to where we move the kernel image temporarily for safe in-place decompression

[PinoTsao]

we must enable PAE mode by putting the value of the cr4 register into eax, setting 5 bit in it and loading it again into cr4

==>

we must enable PAE by putting the value of cr4 register into eax, setting the 5th bit and loading it back into cr4

[PinoTsao]

After comparison of the LOAD_PHYSICAL_ADDR and value of the ebx register, we add the offset from the startup_32 where to decompress the compressed kernel image. If the CONFIG_RELOCATABLE option is not enabled during kernel configuration, we just put the default address where to load kernel and add z_extract_offset to it.

To be honest, I think most content of it is wrong, for example, I don't see any reference of z_extract_offset in current code here, maybe in older time it is different.

It is just a calculation of physical address where to place the decompressed kernel, if we don't have CONFIG_RELOCATABLE, it is the LOAD_PHYSICAL_ADDR, or else, it will be the address of %ebp(protect mode kernel loaded address) aligned to BP_kernel_alignment, while no less than LOAD_PHYSICAL_ADDR.

I find the commit which drop the symbol: z_extract_offset

[WarpspeedSCP]

I'm currently doing some proofreading work where I try to correct spelling, grammar and formatting mistakes, and I've found another thing which seems a bit off...

on line 549,

Here we put the MSR_EFER flag (which is defined in arch/x86/include/asm/msr-index.h) in the ecx register and call rdmsr instruction which reads the MSR register. After rdmsr executes, we will have the resulting data in edx:eax which depends on the ecx value. We check the EFER_LME bit with the btsl instruction and write data from eax to the MSR register with the wrmsr instruction.

here, shouldn't eax in

We check the EFER_LME bit with the btsl instruction and write data from eax to the MSR register with the wrmsr instruction.

be edx:eax?

[mudongliang]

Right. wrmsr instruction writes the contents of registers EDX:EAX into the 64-bit model specific register (MSR) specified in the ECX register.