Merge pull request #909 from 0xAX/link-checker

ci: add link-checker to check links for now in Boot

Author: 0xAX

.github/workflows/check-links.yaml

@@ -0,0 +1,37 @@
+name: check links
+
+on:
+  workflow_dispatch:
+  push:
+    branches:
+      - main
+      - master
+  pull_request:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  check-links:
+    name: check-links
+    runs-on:
+      - ubuntu-22.04
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v6
+
+      - name: Check links with lychee
+        uses: lycheeverse/lychee-action@v2
+        with:
+          # Check README.md and all files in Booting directory
+          args: |
+            --verbose
+            --no-progress
+            --max-retries 3
+            --timeout 20
+            README.md
+            'Booting/*.md'
+          fail: true
+        env:
+          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

.github/workflows/generate-e-books.yaml

@@ -1,10 +1,7 @@
 name: Generate e-books
 
 on:
-  pull_request:
-    branches:
-      - master
-  workflow_dispatch: {}  # For manual runs.
+  workflow_dispatch: {}
 
 jobs:
   build-for-pr:

Booting/linux-bootstrap-1.md

@@ -76,7 +76,7 @@ In real mode, the base address is normally formed by shifting the 16-bit segment
 '0xfffffff0'
 ```
 
-We got `0xFFFFFFF0`, which is 16 bytes below 4GB. This is the very first address where the CPU starts the execution after reset. This address has special name - [reset vector](https://en.wikipedia.org/wiki/Reset_vector). It is the memory location at which the CPU expects to find the first instruction to execute after reset. Usually it contains a [jump](https://en.wikipedia.org/wiki/JMP_%28x86_instruction%29) (`jmp`) instruction which points to the [BIOS](https://en.wikipedia.org/wiki/BIOS) or [UEFI](https://en.wikipedia.org/wiki/UEFI) entry point. For example, if we take a look at the [source code](https://github.com/coreboot/coreboot/blob/main/src/cpu/x86/reset16.S) of the [coreboot](https://www.coreboot.org/), we will see it there:
+We got `0xFFFFFFF0`, which is 16 bytes below 4GB. This is the very first address where the CPU starts the execution after reset. This address has special name - [reset vector](https://en.wikipedia.org/wiki/Reset_vector). It is the memory location at which the CPU expects to find the first instruction to execute after reset. Usually it contains a [jump](https://en.wikipedia.org/wiki/JMP_%28x86_instruction%29) (`jmp`) instruction which points to the [BIOS](https://en.wikipedia.org/wiki/BIOS) or [UEFI](https://en.wikipedia.org/wiki/UEFI) entry point. For example, if we take a look at the [source code](https://github.com/coreboot/coreboot/blob/main/src/cpu/x86/entry16.S) of the [coreboot](https://www.coreboot.org/), we will see it there:
 
 <!-- https://raw.githubusercontent.com/coreboot/coreboot/refs/heads/main/src/cpu/x86/entry16.S#L155-L159 -->
 ```assembly
@@ -180,7 +180,7 @@ From this point onwards, the BIOS hands control over to the bootloader.
 
 ## The Bootloader Stage
 
-There are a number of different bootloaders that can boot Linux kernel, such as [GRUB 2](https://www.gnu.org/software/grub/), [syslinux](http://www.syslinux.org/wiki/index.php/The_Syslinux_Project), [systemd-boot](https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/), and others. The Linux kernel has a [Boot protocol](https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/boot.rst) which specifies the requirements for a bootloader to implement Linux support. In this chapter, we will take a short look how GRUB 2 does loading.
+There are a number of different bootloaders that can boot Linux kernel, such as [GRUB 2](https://www.gnu.org/software/grub/), [syslinux](http://www.syslinux.org/wiki/index.php/The_Syslinux_Project), [systemd-boot](https://github.com/ivandavidov/systemd-boot), and others. The Linux kernel has a [Boot protocol](https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/boot.rst) which specifies the requirements for a bootloader to implement Linux support. In this chapter, we will take a short look how GRUB 2 does loading.
 
 Continuing from where we left off - the BIOS has now selected a boot device, found its boot sector, loaded it into memory and passed control to the code located there. GRUB 2 bootloader consists of multiple [stages](https://www.gnu.org/software/grub/manual/grub/grub.html#Images). The first stage of the boot code is in the [boot.S](https://github.com/rhboot/grub2/blob/master/grub-core/boot/i386/pc/boot.S) source code file. Due to limited amount of space for the first boot sector, this code has only single goal - to load [core image](https://www.gnu.org/software/grub/manual/grub/html_node/Images.html) into memory and jump to it.
 

Booting/linux-bootstrap-2.md

@@ -497,4 +497,5 @@ Here is the list of the links that you may find useful during reading of this ch
 - [BIOS interrupt](https://en.wikipedia.org/wiki/BIOS_interrupt_call)
 - [Intel SpeedStep](http://en.wikipedia.org/wiki/SpeedStep)
 - [APM](https://en.wikipedia.org/wiki/Advanced_Power_Management)
-- [EDD specification](http://www.t13.org/documents/UploadedDocuments/docs2004/d1572r3-EDD3.pdf)
+- [EDD](https://en.wikipedia.org/wiki/Enhanced_Disk_Drive)
+- [Previous part](linux-bootstrap-1.md)

Booting/linux-bootstrap-4.md

@@ -185,7 +185,7 @@ SYM_FUNC_START(startup_32)
 	cli
 ```
 
-When the direction flag is clear, all string or copy-like operations used for copying data, like for example [stos](http://x86.renejeschke.de/html/file_module_x86_id_306.html) or [scas](http://x86.renejeschke.de/html/file_module_x86_id_287.html), will increment the index registers `esi` or `edi`. We need to clear the direction flag because later we will use string operations for tasks such as clearing space for page tables or copying data.
+When the direction flag is clear, all string or copy-like operations used for copying data, like for example [stos](https://www.felixcloutier.com/x86/stos:stosb:stosw:stosd:stosq) or [scas](https://www.felixcloutier.com/x86/scas:scasb:scasw:scasd), will increment the index registers `esi` or `edi`. We need to clear the direction flag because later we will use string operations for tasks such as clearing space for page tables or copying data.
 
 The next instruction is to disable interrupts - `cli`. We have already seen it in the previous chapter. The interrupts are disabled "twice" because modern bootloaders can load the kernel starting from this point, but not only one that we have seen in the [first chapter](./linux-bootstrap-1.md).
 
@@ -676,4 +676,4 @@ Here is the list of the links that you may find useful during reading of this ch
 - [Physical addresses](https://en.wikipedia.org/wiki/Physical_address)
 - [Model specific registers](http://en.wikipedia.org/wiki/Model-specific_register)
 - [Control registers](https://en.wikipedia.org/wiki/Control_register)
-- [Previous part](https://github.com/0xAX/linux-insides/blob/v4.16/Booting/linux-bootstrap-3.md)
+- [Previous part](linux-bootstrap-3.md)

Booting/linux-bootstrap-5.md

@@ -499,4 +499,4 @@ Here is the list of the links that you can find useful when reading this chapter
 - [Flat memory model](https://en.wikipedia.org/wiki/Flat_memory_model)
 - [Address space layout randomization](https://en.wikipedia.org/wiki/Address_space_layout_randomization)
 - [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format)
-- [Previous part](https://github.com/0xAX/linux-insides/blob/v4.16/Booting/linux-bootstrap-4.md)
+- [Previous part](linux-bootstrap-4.md)

Booting/linux-bootstrap-6.md

@@ -295,7 +295,7 @@ After these sanity checks, the decompressor code begins scanning the system's av
 
 The scanning consists of three potential stages:
 
-1. Scan the memory regions that are not preserved by the [KHO](https://docs.kernel.org/core-api/kho/concepts.html#kho-concepts).
+1. Scan the memory regions that are not preserved by the [KHO](https://docs.kernel.org/next/kho/concepts.html).
 2. Scan the memory regions presented by the [EFI](https://en.wikipedia.org/wiki/Uefi) memory map.
 3. Fallback to scanning the memory regions reported by the [e820](https://en.wikipedia.org/wiki/E820) BIOS service.
 
@@ -418,4 +418,4 @@ The next chapter will be about kernel initialization and we will study the first
 - [e820](https://en.wikipedia.org/wiki/E820)
 - [Time Stamp Counter](https://en.wikipedia.org/wiki/Time_Stamp_Counter)
 - [rdrand instruction](https://en.wikipedia.org/wiki/RdRand)
-- [Previous part](./linux-bootstrap-5.md)
+- [Previous part](linux-bootstrap-5.md)

lychee.toml

@@ -0,0 +1,29 @@
+# Lychee link checker configuration
+# See https://github.com/lycheeverse/lychee for all options
+
+# Maximum number of retries per link
+max_retries = 3
+
+# Timeout per request in seconds
+timeout = 20
+
+# Exclude these URLs from checking (regex patterns)
+exclude = [
+    "twitter\\.com",
+    "x\\.com",
+    "osdev\\.org",
+    "intel.com/*"
+]
+
+# Accept status codes as valid
+accept = [
+    200,   # OK
+    204,   # No Content
+    206,   # Partial Content (for range requests)
+]
+
+# User agent string
+user_agent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
+
+# Check external links
+scheme = ["https", "http"]