Code Wrangling at its Best
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
Continue Reading “Chapter 8 – Moving the Heap onto Virtual Memory”
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.
Every major shift in computing has triggered the same fear: “Is this the end of developers as we know them?” When compilers replaced handwritten machine code, some thought assembly programmers were finished. When high-level languages emerged, others predicted the death of low-level expertise. When frameworks abstracted enormous amounts of boilerplate, people claimed “anyone can build
In today’s developer landscape, many programmers—both new and seasoned—cling to a single coding paradigm as the “one true way,” dismissing others like object-oriented, functional, or event-driven programming as bloated or misguided. But real engineering maturity comes from knowing why each paradigm exists and when to use it. The most successful developers choose their tools based on risk, scalability, and maintainability—not ideology. This article explores why the refusal to evolve beyond one style limits growth, risks project failure, and ignores decades of hard-earned lessons in software design.
Recent Comments