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, '!' 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/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); diff --git a/contributors.md b/contributors.md index cdecae5..c4ef5d0 100644 --- a/contributors.md +++ b/contributors.md @@ -111,3 +111,5 @@ 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) +* [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..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 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 {