From 6b76a0a127ab13171dd6dad6527c5b42cfa4699e Mon Sep 17 00:00:00 2001 From: janis Date: Sat, 18 Jul 2026 21:28:27 +0200 Subject: [PATCH] rewording --- blog/intro.org | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/blog/intro.org b/blog/intro.org index a337e4c..242e159 100644 --- a/blog/intro.org +++ b/blog/intro.org @@ -178,7 +178,7 @@ Because we plan on using builtin functions like =memcpy=, we tell cargo to build Unstable fields in =cargo/config.toml= are unstable cargo features that can otherwise be enabled by passing the =-Z= flag to cargo, as we did above for the =json-target-spec= feature. A list of unstable cargo features can be found [[https://doc.rust-lang.org/cargo/reference/unstable.html][here]]. -=build-std= takes as argument a list of crates to build from the standard library. We only want =core= and =compiler_builtins=, but in the future we may want to add =alloc=. Any crate that is part of the library workspace can be specified here, though some make no sense to specift, or even break cargo. +=build-std= takes as argument a list of crates to build from the standard library. We only want =core= and =compiler_builtins=, but in the future we may want to add =alloc=. Any crate that is part of the library workspace can be specified here, though some make no sense to specify, or even break cargo. =core= implies =compiler_builtins=, but since =build-std= is an unstable feature and may change in the future, we explicitly specify both to be safe. =build-std-features= takes a list of features to pass to the crates specified in =build-std=. @@ -213,7 +213,7 @@ There are a number of strategies for getting a computer to run our kernel, but w Since the launch of Windows 8 in 2012, Microsoft has required that all computers ship with UEFI firmware; as a consequence, almost all modern x86-64 computers will have UEFI firmware. Another strategy would be to act as a UEFI application and letting the firmware load our kernel without bothering with a bootloader, however UEFI is a very complex and heavy specification, requiring a lot more code to get to the fun part of writing our operating system, so instead we will let limine deal with the UEFI part of booting. -Using either limine or UEFI also means we skip over the legacy BIOS boot process which involves setting up the CPU in 16-bit real mode, and switching to 32-bit protected mode before finally switching to 64-bit long mode, which is the mode we are interested in. +Using either limine or UEFI also means we skip over the legacy BIOS boot process which involves setting up the CPU in 16-bit real mode, and switching to 32-bit protected mode before finally switching to 64-bit long mode, which is what we are interested in. We will need to add a few additional dependencies to our =flake.nix=: #+begin_src nix @@ -283,8 +283,7 @@ We will create a =run.sh= script to automate hide away the details of launching #+end_src Lets go through the script step by step: -The first like after the shebang that tells the loader to use =bash= as the interpreter is =set -e=, which means the script will exit immediately if any command returns a failure exit code. -This means that, if we for example don't have limine installed, the script won't try to create the image or run qemu with an incomplete setup. +The first like after the shebang that tells the loader to use =bash= as the interpreter is =set -e=, which means the script will exit immediately if any command returns a failure exit code: if, for example, limine is not installed, the script won't proceed to create the image or run qemu with an incomplete setup. Our script currently takes a single argument, the path to the kernel binary. Cargo allows us to set a "runner" command in the =.cargo/config.toml= file, which it will call with the path to the binary as the first argument instead of the calling the binary itself. We will make use of this feature to automatically start our kernel in qemu with the help of cargo.