rewording

This commit is contained in:
janis 2026-07-18 21:28:27 +02:00
parent 4cad6a2b17
commit 6b76a0a127
Signed by: janis
SSH key fingerprint: SHA256:bB1qbbqmDXZNT0KKD5c2Dfjg53JGhj7B3CFcLIzSqq8

View file

@ -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.