Merge pull request #1347 from elchukc/fix_typo_start_return_type

add return type on `_start()` in code block

blog/content/edition-2/posts/02-minimal-rust-kernel/index.md

@@ -211,7 +211,7 @@ Our target specification file now looks like this:
 ```
 
 ### Building our Kernel
-Compiling for our new target will use Linux conventions (I'm not quite sure why; I assume it's just LLVM's default). This means that we need an entry point named `_start` as described in the [previous post]:
+Compiling for our new target will use Linux conventions, since the ld.lld linker-flavor instructs llvm to compile with the `-flavor gnu` flag (for more linker options, see [the rustc documentation](https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-flavor)). This means that we need an entry point named `_start` as described in the [previous post]:
 
 [previous post]: @/edition-2/posts/01-freestanding-rust-binary/index.md
 

blog/content/edition-2/posts/03-vga-text-buffer/index.md

@@ -656,7 +656,7 @@ Now we can use `println` in our `_start` function:
 // in src/main.rs
 
 #[no_mangle]
-pub extern "C" fn _start() {
+pub extern "C" fn _start() -> ! {
     println!("Hello World{}", "!");
 
     loop {}

blog/content/edition-2/posts/04-testing/index.md

@@ -91,7 +91,7 @@ When we run `cargo test` now, we see that it now succeeds (if it doesn't, see th
 
 <div class = "warning">
 
-**Note:** There is currently a bug in cargo that leads to "duplicate lang item" errors on `cargo test` in some cases. It occurs when you have set `panic = "abort"` for a profile in your `Cargo.toml`. Try removing it, then `cargo test` should work. Alternatively, if that doesn't work, then add `panic-abort-tests = true` to the `[unstable]` section of your `.config/cargo.toml` file. See the [cargo issue](https://github.com/rust-lang/cargo/issues/7359) for more information on this.
+**Note:** There is currently a bug in cargo that leads to "duplicate lang item" errors on `cargo test` in some cases. It occurs when you have set `panic = "abort"` for a profile in your `Cargo.toml`. Try removing it, then `cargo test` should work. Alternatively, if that doesn't work, then add `panic-abort-tests = true` to the `[unstable]` section of your `.cargo/config.toml` file. See the [cargo issue](https://github.com/rust-lang/cargo/issues/7359) for more information on this.
 
 </div>
 

blog/content/edition-2/posts/09-paging-implementation/index.md

@@ -292,7 +292,7 @@ The `bootloader` crate defines a [`BootInfo`] struct that contains all the infor
 
 - The `memory_map` field contains an overview of the available physical memory. This tells our kernel how much physical memory is available in the system and which memory regions are reserved for devices such as the VGA hardware. The memory map can be queried from the BIOS or UEFI firmware, but only very early in the boot process. For this reason, it must be provided by the bootloader because there is no way for the kernel to retrieve it later. We will need the memory map later in this post.
 - The `physical_memory_offset` tells us the virtual start address of the physical memory mapping. By adding this offset to a physical address, we get the corresponding virtual address. This allows us to access arbitrary physical memory from our kernel.
-- This physical memory offset can be customized by adding a `[package.metadata.bootloader]` table in Cargo.toml and setting the field `physical-memory-offset = "0x0000f00000000000"` (or any other value). However, note that the bootloader can panic if it runs into physical address values that start to overlap with the the space beyond the offset, i.e., areas it would have previously mapped to some other early physical addresses. So in general, the higher the value (> 1 TiB), the better.
+- This physical memory offset can be customized by adding a `[package.metadata.bootloader]` table in Cargo.toml and setting the field `physical-memory-offset = "0x0000f00000000000"` (or any other value). However, note that the bootloader can panic if it runs into physical address values that start to overlap with the space beyond the offset, i.e., areas it would have previously mapped to some other early physical addresses. So in general, the higher the value (> 1 TiB), the better.
 
 The bootloader passes the `BootInfo` struct to our kernel in the form of a `&'static BootInfo` argument to our `_start` function. We don't have this argument declared in our function yet, so let's add it: