From abf4f684a5e20033bcf657babba1c77025292227 Mon Sep 17 00:00:00 2001 From: Alexander Kuleshov Date: Mon, 27 Nov 2017 00:55:54 +0600 Subject: [PATCH 1/5] bootstrap1: .org directive is useless in a case of binary output so we may remove one. Thank you @slo Signed-off-by: Alexander Kuleshov --- Booting/linux-bootstrap-1.md | 1 - 1 file changed, 1 deletion(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index 65d24f1..cb03244 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -110,7 +110,6 @@ For example: ; Note: this example is written in Intel Assembly syntax ; [BITS 16] -[ORG 0x7c00] boot: mov al, '!' From ec3fa13996a07c505a0dc7b76558e0dc44e5ac55 Mon Sep 17 00:00:00 2001 From: Fupan Li Date: Wed, 29 Nov 2017 11:58:37 +0800 Subject: [PATCH 2/5] spinlock: fix the wrong function name of arch_spin_lock It should be arch_spin_unlock instead of arch_spin_lock. Signed-off-by: Fupan Li --- SyncPrim/sync-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SyncPrim/sync-1.md b/SyncPrim/sync-1.md index 76ea46f..b58e9c6 100644 --- a/SyncPrim/sync-1.md +++ b/SyncPrim/sync-1.md @@ -373,7 +373,7 @@ If one process held a lock and a second process started to execute the `arch_spi and the next iteration of the loop will be started. If these values will be equal, this means that the process which held this lock, released this lock and the next process may acquire the lock. -The `spin_unlock` operation goes through the all macros/function as `spin_lock`, of course with `unlock` prefix. In the end the `arch_spin_unlock` function will be called. If we will look at the implementation of the `arch_spin_lock` function, we will see that it increases `head` of the `lock tickets` list: +The `spin_unlock` operation goes through the all macros/function as `spin_lock`, of course with `unlock` prefix. In the end the `arch_spin_unlock` function will be called. If we will look at the implementation of the `arch_spin_unlock` function, we will see that it increases `head` of the `lock tickets` list: ```C __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); From 723b07605cadbd70a3bdf0339790b5169e8b0ba3 Mon Sep 17 00:00:00 2001 From: Firo Yang Date: Wed, 29 Nov 2017 16:21:45 +0800 Subject: [PATCH 3/5] In the following expression, we add the value of phys_base to the rax register, not the address of phys_base. addq phys_base(%rip), %rax BTW, the value of phys_base = the actual loaded physical address of kernel after relocation - the likned physical address of kernel. Signed-off-by: Firo Yang --- Initialization/linux-initialization-1.md | 2 +- contributors.md | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Initialization/linux-initialization-1.md b/Initialization/linux-initialization-1.md index b0fecd5..eb5ff1e 100644 --- a/Initialization/linux-initialization-1.md +++ b/Initialization/linux-initialization-1.md @@ -270,7 +270,7 @@ That's all for now. Our early paging is prepared and we just need to finish last Last preparation before jump at the kernel entry point -------------------------------------------------------------------------------- -After that we jump to the label `1` we enable `PAE`, `PGE` (Paging Global Extension) and put the physical address of the `phys_base` (see above) to the `rax` register and fill `cr3` register with it: +After that we jump to the label `1` we enable `PAE`, `PGE` (Paging Global Extension) and put the content of the `phys_base` (see above) to the `rax` register and fill `cr3` register with it: ```assembly 1: diff --git a/contributors.md b/contributors.md index cdecae5..fd60e7a 100644 --- a/contributors.md +++ b/contributors.md @@ -111,3 +111,4 @@ Thank you to all contributors: * [Cornelius Diekmann](https://github.com/diekmann) * [Andrés Rojas](https://github.com/c0r3dump3d) * [Beomsu Kim](https://github.com/0xF0D0) +* [Firo Yang](https://github.com/firogh) From 70cfea09068ec1e799c730dfb56632567ca60bd2 Mon Sep 17 00:00:00 2001 From: Edward Hu Date: Thu, 30 Nov 2017 21:24:32 -0600 Subject: [PATCH 4/5] grammer adjustment and concept clarifying --- contributors.md | 1 + mm/linux-mm-1.md | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contributors.md b/contributors.md index fd60e7a..c4ef5d0 100644 --- a/contributors.md +++ b/contributors.md @@ -112,3 +112,4 @@ Thank you to all contributors: * [Andrés Rojas](https://github.com/c0r3dump3d) * [Beomsu Kim](https://github.com/0xF0D0) * [Firo Yang](https://github.com/firogh) +* [Edward Hu](https://github.com/BDHU) \ No newline at end of file diff --git a/mm/linux-mm-1.md b/mm/linux-mm-1.md index bc260b6..9a7c195 100644 --- a/mm/linux-mm-1.md +++ b/mm/linux-mm-1.md @@ -12,7 +12,7 @@ Memblock Memblock is one of the methods of managing memory regions during the early bootstrap period while the usual kernel memory allocators are not up and running yet. Previously it was called `Logical Memory Block`, but with the [patch](https://lkml.org/lkml/2010/7/13/68) by Yinghai Lu, it was renamed to the `memblock`. As Linux kernel for `x86_64` architecture uses this method. We already met `memblock` in the [Last preparations before the kernel entry point](http://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-3.html) part. And now it's time to get acquainted with it closer. We will see how it is implemented. -We will start to learn `memblock` from the data structures. Definitions of the all data structures can be found in the [include/linux/memblock.h](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/include/linux/memblock.h) header file. +We will start to learn `memblock` from the data structures. Definitions of all logical memory block related data structures can be found in the [include/linux/memblock.h](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/include/linux/memblock.h) header file. The first structure has the same name as this part and it is: @@ -28,7 +28,7 @@ struct memblock { }; ``` -This structure contains five fields. First is `bottom_up` which allows allocating memory in bottom-up mode when it is `true`. Next field is `current_limit`. This field describes the limit size of the memory block. The next three fields describe the type of the memory block. It can be: reserved, memory and physical memory if the `CONFIG_HAVE_MEMBLOCK_PHYS_MAP` configuration option is enabled. Now we see yet another data structure - `memblock_type`. Let's look at its definition: +This structure contains five fields. First is `bottom_up` which allows allocating memory in bottom-up mode when it is `true`. Next field is `current_limit`. This field describes the limit size of the memory block. The next three fields describe the type of the memory block. It can be: reserved, memory and physical memory (physical memory is available if the `CONFIG_HAVE_MEMBLOCK_PHYS_MAP` configuration option is enabled). Now we see yet another data structure - `memblock_type`. Let's look at its definition: ```C struct memblock_type { @@ -39,7 +39,7 @@ struct memblock_type { }; ``` -This structure provides information about the memory type. It contains fields which describe the number of memory regions which are inside the current memory block, the size of all memory regions, the size of the allocated array of the memory regions and pointer to the array of the `memblock_region` structures. `memblock_region` is a structure which describes a memory region. Its definition is: +This structure provides information about the memory type. It contains fields which describe the number of memory regions inside the current memory block, the size of all memory regions, the size of the allocated array of the memory regions, and a pointer to the array of the `memblock_region` structures. `memblock_region` is a structure which describes a memory region. Its definition is: ```C struct memblock_region { From a7b68a882567aa1b774344762a26ac0c8a66c3f5 Mon Sep 17 00:00:00 2001 From: Edward Hu Date: Thu, 30 Nov 2017 21:27:03 -0600 Subject: [PATCH 5/5] word change --- mm/linux-mm-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/linux-mm-1.md b/mm/linux-mm-1.md index 9a7c195..931ce39 100644 --- a/mm/linux-mm-1.md +++ b/mm/linux-mm-1.md @@ -12,7 +12,7 @@ Memblock Memblock is one of the methods of managing memory regions during the early bootstrap period while the usual kernel memory allocators are not up and running yet. Previously it was called `Logical Memory Block`, but with the [patch](https://lkml.org/lkml/2010/7/13/68) by Yinghai Lu, it was renamed to the `memblock`. As Linux kernel for `x86_64` architecture uses this method. We already met `memblock` in the [Last preparations before the kernel entry point](http://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-3.html) part. And now it's time to get acquainted with it closer. We will see how it is implemented. -We will start to learn `memblock` from the data structures. Definitions of all logical memory block related data structures can be found in the [include/linux/memblock.h](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/include/linux/memblock.h) header file. +We will start to learn `memblock` from the data structures. Definitions of all logical-memory-block-related data structures can be found in the [include/linux/memblock.h](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/include/linux/memblock.h) header file. The first structure has the same name as this part and it is: