Chapter 10 — Timer-Driven Preemptive Multitasking

This entry is part 10 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 9, we built cooperative multitasking: That works, but it has a major weakness: A thread like that can monopolize the CPU forever. This chapter adds the next step: timer-driven preemption. With preemptive scheduling: OSDev describes preemptive multitasking as scheduling where an interrupt, usually timer-driven, allows the kernel to take control away from the

Chapter 41 — Dynamic /programs from the Program Registry

This entry is part 4 of 4 in the series AI for Software Development

Chapter 40 closed the loop on shell-visible background jobs by giving them local %N references. That matters here because it gave us a stable chapter boundary:the shell can now be scripted without hardcoding fragile PIDs, so the filesystem work that follows can focus on the namespace itself instead of fighting the test harness. The next

Chapter 9 — Cooperative Multitasking and Kernel Threads

This entry is part 9 of 10 in the series Writing A Linux Style Operating System From Scratch

We now have enough foundation to start multitasking: This chapter adds the first scheduler. Not a preemptive scheduler yet. A cooperative scheduler. That means each kernel thread keeps running until it voluntarily calls: “` cthread_yield(); textkernel thread objectper-thread kernel stackready queuex86 context switch assemblythread_create()thread_yield()thread_exit()round-robin cooperative schedulingtwo-thread test textcreate two kernel threadsswitch between them cooperativelyprove both

Chapter 8 – Moving the Heap onto Virtual Memory

Chapter 8 – Moving the Heap onto Virtual Memory
This entry is part 8 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 6, the kernel heap still depended on low identity-mapped physical pages. That worked as a bootstrap step, but it tied the heap to the first 16 MiB of RAM. In Chapter 7, we added a real VMM and proved that the kernel can map and unmap pages anywhere the page tables allow. That

Chapter 7 — A Real Virtual Memory Mapping Layer

Chapter 7 — A Real Virtual Memory Mapping Layer
This entry is part 7 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 5 we enabled paging, but only with a fixed identity map: In Chapter 6 we built a heap, but it still had an important weakness: because only the first 16 MiB were identity-mapped. Now we fix the architectural problem. This chapter adds a small virtual memory manager, or VMM: This lets the kernel

Chapter 6 — Building the First Kernel Heap

Chapter 6 — Building the First Kernel Heap
This entry is part 6 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 5, we enabled paging with a simple identity map: That gave us a working paged kernel, but not yet a comfortable way to allocate variable-sized objects. The physical memory manager gives us whole pages: But kernel code usually needs smaller objects: So this chapter builds the first kernel heap. We will keep it

Chapter 5 — Turning On Paging

Chapter 5 — Turning On Paging
This entry is part 5 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 4, we built the first memory-management layer: Now we add the next layer: paging. Paging lets the CPU translate a virtual address into a physical address through page tables. In 32-bit x86 paging without PAE, a virtual address is split into a page-directory index, page-table index, and page offset; page directories and page

Chapter 4 — Reading the Memory Map and Building a Physical Page Allocator

Chapter 4 — Reading the Memory Map and Building a Physical Page Allocator
This entry is part 4 of 10 in the series Writing A Linux Style Operating System From Scratch

Before we add paging, a heap, processes, filesystems, or user programs, the kernel must answer a basic question: Which physical 4 KiB pages of RAM are safe for me to use? Right now, our kernel can boot, print text, catch CPU exceptions, and receive timer/keyboard interrupts. But it still cannot safely allocate memory. This chapter

Chapter 3 — Hardware Interrupts: PIC, PIT Timer, and Keyboard Input

Chapter 3 — Hardware Interrupts: PIC, PIT Timer, and Keyboard Input
This entry is part 3 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 2 we taught the CPU how to call our code when something goes wrong: Now we will teach the machine how to call our code when hardware wants attention: This is the first step toward a living kernel. A timer interrupt eventually gives us scheduling. Keyboard input eventually gives us a kernel monitor

Chapter 2 — GDT, IDT, and Surviving Your First Kernel Crash

Chapter 2 — GDT, IDT, and Surviving Your First Kernel Crash
This entry is part 2 of 10 in the series Writing A Linux Style Operating System From Scratch

In Chapter 1, we got control of the machine: Now we need something more important than printing text: we need the CPU to call our code when something goes wrong. Right now, if the kernel executes an invalid instruction, divides by zero, touches unmapped memory later, or faults during setup, the machine may reset, hang,