From 52a79a731988426d7d699aea1c3e7bd5accbe6cc Mon Sep 17 00:00:00 2001 From: ruthgrace Date: Sat, 31 Oct 2015 02:47:55 -0400 Subject: [PATCH 1/8] fixed grammar in linux-bootstrap-1.md, Bootloader section --- Booting/linux-bootstrap-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index e0b3a34..871c0e8 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -241,7 +241,7 @@ So when the bootloader transfers control to the kernel, it starts at: 0x1000 + X + sizeof(KernelBootSector) + 1 ``` -where `X` is the address of the kernel bootsector loaded. In my case `X` is `0x10000`, as we can see in a memory dump: +where `X` is the address of the kernel boot sector loaded. In my case `X` is `0x10000`, as we can see in a memory dump: ![kernel first address](http://oi57.tinypic.com/16bkco2.jpg) From a02a5d274cf8fd7d27e16f68e9246cb5f7ab463f Mon Sep 17 00:00:00 2001 From: ruthgrace Date: Sat, 31 Oct 2015 03:10:57 -0400 Subject: [PATCH 2/8] fixed grammar in linux-bootstrap-1.md, BSS Setup section --- Booting/linux-bootstrap-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index e0b3a34..c3c70cd 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -458,7 +458,7 @@ The BSS section is used to store statically allocated, uninitialized data. Linux rep; stosl ``` -First of all the [__bss_start](https://github.com/torvalds/linux/blob/master/arch/x86/boot/setup.ld#L47) address is moved into `di` and the `_end + 3` address (+3 - aligns to 4 bytes) is moved into `cx`. The `eax` register is cleared (using an `xor` instruction), and the bss section size (`cx`-`di`) is calculated and put into `cx`. Then, `cx` is divided by four (the size of a 'word'), and the `stosl` instruction is repeatedly used, storing the value of `eax` (zero) into the address pointed to by `di`, automatically increasing `di` by four (this occurs until `cx` reaches zero). The net effect of this code is that zeros are written through all words in memory from `__bss_start` to `_end`: +First of all the [__bss_start](https://github.com/torvalds/linux/blob/master/arch/x86/boot/setup.ld#L47) address is moved into `di` and the `_end + 3` address (+3 - aligns to 4 bytes) is moved into `cx`. The `eax` register is cleared (using a `xor` instruction), and the bss section size (`cx`-`di`) is calculated and put into `cx`. Then, `cx` is divided by four (the size of a 'word'), and the `stosl` instruction is repeatedly used, storing the value of `eax` (zero) into the address pointed to by `di`, automatically increasing `di` by four (this occurs until `cx` reaches zero). The net effect of this code is that zeros are written through all words in memory from `__bss_start` to `_end`: ![bss](http://oi59.tinypic.com/29m2eyr.jpg) From 03a327ad227b1bb48f962f58c96d23fb0877cef7 Mon Sep 17 00:00:00 2001 From: ruthgrace Date: Sat, 31 Oct 2015 03:12:04 -0400 Subject: [PATCH 3/8] fixed grammar in linux-bootstrap-1.md, Jump to main section --- Booting/linux-bootstrap-1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index e0b3a34..8555a4a 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -465,13 +465,13 @@ First of all the [__bss_start](https://github.com/torvalds/linux/blob/master/arc Jump to main -------------------------------------------------------------------------------- -That's all, we have the stack, BSS so we can jump to the `main()` C function: +That's all, we have the stack and BSS so we can jump to the `main()` C function: ```assembly calll main ``` -The `main()` function is located in [arch/x86/boot/main.c](https://github.com/torvalds/linux/blob/master/arch/x86/boot/main.c). What this does, you can read in the next part. +The `main()` function is located in [arch/x86/boot/main.c](https://github.com/torvalds/linux/blob/master/arch/x86/boot/main.c). You can read about what this does in the next part. Conclusion -------------------------------------------------------------------------------- From f8083757de619ebc3d24b8500c04d504ca7a834d Mon Sep 17 00:00:00 2001 From: ruthgrace Date: Sat, 31 Oct 2015 02:38:25 -0400 Subject: [PATCH 4/8] fixed grammar in linux-bootstrap-1.md, From the bootloader to [the] kernel section --- Booting/linux-bootstrap-1.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index e0b3a34..0fa1258 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -1,10 +1,10 @@ Kernel booting process. Part 1. ================================================================================ -From the bootloader to kernel +From the bootloader to the kernel -------------------------------------------------------------------------------- -If you have read my previous [blog posts](http://0xax.blogspot.com/search/label/asm), you can see that sometime ago I started to get involved with low-level programming. I wrote some posts about x86_64 assembly programming for Linux. At the same time, I started to dive into the Linux source code. I have a great interest in understanding how low-level things work, how programs run on my computer, how they are located in memory, how the kernel manages processes and memory, how the network stack works on low-level and many many other things. So, I decided to write yet another series of posts about the Linux kernel for **x86_64**. +If you have read my previous [blog posts](http://0xax.blogspot.com/search/label/asm), you can see that sometime ago I started to get involved with low-level programming. I wrote some posts about x86_64 assembly programming for Linux. At the same time, I started to dive into the Linux source code. I have a great interest in understanding how low-level things work, how programs run on my computer, how they are located in memory, how the kernel manages processes and memory, how the network stack works at a low level and many many other things. So, I decided to write yet another series of posts about the Linux kernel for **x86_64**. Note that I'm not a professional kernel hacker and I don't write code for the kernel at work. It's just a hobby. I just like low-level stuff, and it is interesting for me to see how these things work. So if you notice anything confusing, or if you have any questions/remarks, ping me on twitter [0xAX](https://twitter.com/0xAX), drop me an [email](anotherworldofworld@gmail.com) or just create an [issue](https://github.com/0xAX/linux-insides/issues/new). I appreciate it. All posts will also be accessible at [linux-insides](https://github.com/0xAX/linux-insides) and if you find something wrong with my English or the post content, feel free to send a pull request. @@ -58,7 +58,7 @@ which is 65519 bytes over first megabyte. Since only one megabyte is accessible Ok, now we know about real mode and memory addressing. Let's get back to discuss about register values after reset: -`CS` register consists of two parts: the visible segment selector and hidden base address. We know predefined `CS` base and `IP` value, so the logical address will be: +The `CS` register consists of two parts: the visible segment selector and hidden base address. We know the predefined `CS` base and `IP` value, so the logical address will be: ``` 0xffff0000:0xfff0 @@ -127,7 +127,7 @@ Build and run it with: nasm -f bin boot.nasm && qemu-system-x86_64 boot ``` -This will instruct [QEMU](http://qemu.org) to use the `boot` binary we just built as a disk image. Since the binary generated by the assembly code above fulfills the requirements of the boot sector (the origin is set to `0x7c00`, and we end with the magic sequence), QEMU will treat the binary as the master boot record(MBR) of a disk image. +This will instruct [QEMU](http://qemu.org) to use the `boot` binary we just built as a disk image. Since the binary generated by the assembly code above fulfills the requirements of the boot sector (the origin is set to `0x7c00`, and we end with the magic sequence), QEMU will treat the binary as the master boot record (MBR) of a disk image. You will see: @@ -144,7 +144,7 @@ objdump -D -b binary -mi386 -Maddr16,data16,intel boot A real-world boot sector has code to continue the boot process and the partition table instead of a bunch of 0's and an exclamation mark :) From this point onwards, BIOS hands over control to the bootloader. -**NOTE**: As you can read above the CPU is in real mode. In real mode, calculating the physical address in memory is done as following: +**NOTE**: As you can read above the CPU is in real mode. In real mode, calculating the physical address in memory is done as follows: ``` PhysicalAddress = Segment * 16 + Offset From 2ee9de6059cbbfd7d9c8654cb95f321c860f8898 Mon Sep 17 00:00:00 2001 From: Aaron Ouellette Date: Sun, 1 Nov 2015 19:12:42 -0500 Subject: [PATCH 5/8] some gramatical fixes, clarifications --- Misc/contribute.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Misc/contribute.md b/Misc/contribute.md index da23d46..f4f8d4e 100644 --- a/Misc/contribute.md +++ b/Misc/contribute.md @@ -293,7 +293,7 @@ $ git pull upstream master After this my local repository with the Linux kernel source code is synced with the [mainline](https://github.com/torvalds/linux) repository. Now we can make some changes in the source code. As I already wrote, I have no advice for you where you can start and what `TODO` in the Linux kernel. But the best place for newbies is `staging` tree. In other words the set of drivers from the [drivers/staging](https://github.com/torvalds/linux/tree/master/drivers/staging). The maintainer of the `staging` tree is [Greg Kroah-Hartman](https://en.wikipedia.org/wiki/Greg_Kroah-Hartman) and the `staging` tree is that place where your trivial patch can be accepted. Let's look on a simple example that describes how to generate patch, check it and send to the [Linux kernel mail listing](https://lkml.org/). -If we will look in the driver for the [Digi International EPCA PCI](https://github.com/torvalds/linux/tree/master/drivers/staging/dgap) based devices, we will see the `dgap_sindex` function on line 295: +If we look in the driver for the [Digi International EPCA PCI](https://github.com/torvalds/linux/tree/master/drivers/staging/dgap) based devices, we will see the `dgap_sindex` function on line 295: ```C static char *dgap_sindex(char *string, char *group) @@ -369,7 +369,7 @@ We've passed name of the branch (`master` in this case) to the `format-patch` co $ git format-patch master --stdout > dgap-patch-1.patch ``` -The last step after we have generated our patch is just to send it to the Linux kernel mail listing. Of course you can use any email client, but the `Git` provides special command for this: `git send-email`. Before you will send your patch, you need to know where to send it. Yes, you can send it just to the Linux kernel mail listing address which is `linux-kernel@vger.kernel.org`, but there is a high probability that the patch will be ignored, because as you may already know there is the large flow of messages on the Linux kernel mail listing. The better way will be send to a maintainer of subsystem where you have made changes. We can find maintainer and other related guys who has touched the code with the `get_maintainer.pl` script. All of you need is just pass file or directory where you wrote a code. Go to the root directory with source code of the Linux kernel and execute it: +The last step after we have generated our patch is to send it to the Linux kernel mailing list. Of course, you can use any email client, `git` provides a special command for this: `git send-email`. Before you send your patch, you need to know where to send it. Yes, you can just send it to the Linux kernel mailing list address which is `linux-kernel@vger.kernel.org`, but it is very likely that the patch will be ignored, because of the large flow of messages. The better choice would be to send the patch to the maintainers of the subsystem where you have made changes. To find the names of these maintainers use the `get_maintainer.pl` script. All you need to do is pass the file or directory where you wrote code. ``` $ ./scripts/get_maintainer.pl -f drivers/staging/dgap/dgap.c @@ -394,7 +394,7 @@ $ git send-email --to "Lidza Louina " \ --cc "linux-kernel@vger.kernel.org" ``` -That's all. The patch is sent and now only have to wait feedback from the Linux kernel developers. After you will sent a patch and a maintainer accepted it, you will find it in the maintainer's repository (for example [patch](https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=b9f7f1d0846f15585b8af64435b6b706b25a5c0b) that you saw in this part) and after some time a maintainer will send pull request to Linus and you will see your patch in the mainline repository. +That's all. The patch is sent and now you only have to wait for feedback from the Linux kernel developers. After you send a patch and a maintainer accepts it, you will find it in the maintainer's repository (for example [patch](https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=b9f7f1d0846f15585b8af64435b6b706b25a5c0b) that you saw in this part) and after some time the maintainer will send a pull request to Linus and you will see your patch in the mainline repository. That's all. @@ -403,7 +403,7 @@ Some advice In the end of this part I want to give you some advice that will describe what to do and what not to do during development of the Linux kernel: -* Think, Think, Think. And think again before you decided to send a patch. +* Think, Think, Think. And think again before you decide to send a patch. * Each time when you have changed something in the Linux kernel source code - compile it. After any changes. Again and again. Nobody likes changes that don't even compile. From 3ed521464e99a8ff2f8d438592a605a716a268e2 Mon Sep 17 00:00:00 2001 From: Aaron Ouellette Date: Thu, 12 Nov 2015 21:20:02 -0500 Subject: [PATCH 6/8] another grammar fix --- Misc/contribute.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Misc/contribute.md b/Misc/contribute.md index f4f8d4e..da7bfed 100644 --- a/Misc/contribute.md +++ b/Misc/contribute.md @@ -452,7 +452,7 @@ It's important that your email be in the [plain text](https://en.wikipedia.org/w [PATCH v2] staging/dgap: Use strpbrk() instead of dgap_sindex() ``` -Also it must contain changelog that will describe all changes changes from previous patch versions. Of course, this is not an exhaustive list of requirements for Linux kernel development, but some of the most important items were addressed. +Also it must contain a changelog that describes all changes from previous patch versions. Of course, this is not an exhaustive list of requirements for Linux kernel development, but some of the most important items were addressed. Happy Hacking! From bd7d8e6af00727295ceeebe79dd78b157db4cf33 Mon Sep 17 00:00:00 2001 From: zhaoxiaoqiang Date: Wed, 25 Nov 2015 18:34:32 +0800 Subject: [PATCH 7/8] fix logic error about KEEP_SEGMENTS flags --- Booting/linux-bootstrap-4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Booting/linux-bootstrap-4.md b/Booting/linux-bootstrap-4.md index f2a6fca..46a2f01 100644 --- a/Booting/linux-bootstrap-4.md +++ b/Booting/linux-bootstrap-4.md @@ -153,7 +153,7 @@ and if `KEEP_SEGMENTS` is not set, we need to set `ds`, `ss` and `es` registers movl %eax, %ss ``` -remember that `__BOOT_DS` is `0x18` (index of data segment in the Global Descriptor Table). If `KEEP_SEGMENTS` is not set, we jump to the label `1f` or update segment registers with `__BOOT_DS` if this flag is set. +remember that `__BOOT_DS` is `0x18` (index of data segment in the Global Descriptor Table). If `KEEP_SEGMENTS` is set, we jump to the label `1f` or update segment registers with `__BOOT_DS` if this flag is not set. If you read the previous [part](https://github.com/0xAX/linux-insides/blob/master/Booting/linux-bootstrap-3.md), you can remember that we already updated segment registers in the [arch/x86/boot/pmjump.S](https://github.com/torvalds/linux/blob/master/arch/x86/boot/pmjump.S), so why do we need to set up it again? Actually linux kernel also has the 32-bit boot protocol, so `startup_32` can be the first function which will be executed right after a bootloader transfers control to the kernel. From a29d64e17151a36e19f553cb4d890f78c974aa66 Mon Sep 17 00:00:00 2001 From: Shravan Shandilya Date: Sun, 6 Dec 2015 21:19:39 +0530 Subject: [PATCH 8/8] Kernel is out of context till this point --- Booting/linux-bootstrap-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Booting/linux-bootstrap-1.md b/Booting/linux-bootstrap-1.md index fa8b2bb..c04c242 100644 --- a/Booting/linux-bootstrap-1.md +++ b/Booting/linux-bootstrap-1.md @@ -97,7 +97,7 @@ SECTIONS { } ``` -Now the BIOS starts: after initializing and checking the hardware, it needs to find a bootable device. A boot order is stored in the BIOS configuration, controlling which devices the kernel attempts to boot from. When attempting to boot from a hard drive, the BIOS tries to find a boot sector. On hard drives partitioned with an MBR partition layout, the boot sector is stored in the first 446 bytes of the first sector (which is 512 bytes). The final two bytes of the first sector are `0x55` and `0xaa`, which signals the BIOS that this device is bootable. For example: +Now the BIOS starts: after initializing and checking the hardware, it needs to find a bootable device. A boot order is stored in the BIOS configuration, controlling which devices the BIOS attempts to boot from. When attempting to boot from a hard drive, the BIOS tries to find a boot sector. On hard drives partitioned with an MBR partition layout, the boot sector is stored in the first 446 bytes of the first sector (which is 512 bytes). The final two bytes of the first sector are `0x55` and `0xaa`, which signals the BIOS that this device is bootable. For example: ```assembly ;