Code Wrangling at its Best
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
Continue Reading “Chapter 7 — A Real Virtual Memory Mapping Layer”
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
Continue Reading “Chapter 6 — Building the First Kernel Heap”
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
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
Continue Reading “Chapter 4 — Reading the Memory Map and Building a Physical Page Allocator”
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
Continue Reading “Chapter 3 — Hardware Interrupts: PIC, PIT Timer, and Keyboard Input”
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,
Continue Reading “Chapter 2 — GDT, IDT, and Surviving Your First Kernel Crash”
Today, we are beginning a new article series: “Writing a Linux-Style Operating System From Scratch.” In this series, we will walk step by step through the process of creating our own operating system from the ground up. Many operating system tutorials stop shortly after the system boots and prints a simple message on the screen.
Continue Reading “Writing a Linux-style Operating System From Scratch”
Together, these tools allow us to assemble, compile, link, inspect, and transform kernel binaries without using the host operating system’s normal compiler target.
Purpose This design describes a PocketFlow Creator workflow that accepts a software project folder containing a docs/ subfolder and a project specification, then uses a queue-driven RALF loop to implement the project in ordered, testable increments. The central idea is simple: The LLM may propose.The queue schedules.The gates decide.Git preserves.The human approves high-risk changes. This
Continue Reading “Designing a PocketFlow Creator Flow for Queue-Driven RALF Software Development”
The “Negative Load” Problem Standard linear regulators, like the ubiquitous LM7805, are designed to be “sinks” of power. They take a higher voltage and drop it down, pushing current out of their output pin to power your circuit. However, they are effectively “one-way valves.” In a modern project—especially one involving motors, large inductors, or external
Recent Comments