Code Wrangling at its Best
In Chapter 26, we added: That gave us a real background process path. But our only user program, demo, waits for terminal input: That makes it awkward for runbg, because a background process can compete with the monitor for keyboard input. This chapter adds a second embedded user program: counter does not read from stdin.
Continue Reading “Chapter 27 — A Second User Program for Safe Background Execution”
In Chapter 14, we added the first interactive kernel monitor: That worked, but the monitor command parser was still a chain of if statements: That is fine for five commands, but it does not scale. This chapter cleans that up by adding: The keyboard improvement matters because our monitor is interactive now. A monitor where
Continue Reading “Chapter 15 — Command Tables, Argument Parsing, and Shift-Aware Keyboard Input”
At this point our kernel has enough machinery to become interactive: Now we will build two new layers: The terminal line discipline turns raw keyboard characters into editable input lines. It handles: The kernel monitor is a small command loop: This is not user space yet. It is still a kernel thread. But it gives
Continue Reading “Chapter 14 — Terminal Line Discipline and a Kernel Monitor”
In Chapter 12, we added wait queues and blocking keyboard input: Now we need synchronization primitives that ordinary kernel code can use. This chapter adds: A mutex provides mutual exclusion: only one thread may hold the protected resource at a time. OSDev describes a mutex as a mutual-exclusion mechanism, similar to a binary semaphore, used
Continue Reading “Chapter 13 — Mutexes, Semaphores, and a Console Lock”
In Chapter 11, we added the first blocking primitive: That gave the scheduler a way to remove a thread from the ready queue until a future timer tick. Now we need a more general primitive: This is the foundation for real kernel I/O. A keyboard reader should not spin like this: It should block: This
Continue Reading “Chapter 12 – Wait Queues and Blocking Keyboard Input”
In Chapter 10, we added timer-driven preemption: Now we need the next scheduler capability: blocking. A runnable thread competes for CPU time. A blocked or sleeping thread does not. OSDev describes a blocking process as one that waits for an event, such as a semaphore or message, and is removed from the active scheduling queue
Continue Reading “Chapter 11 — Blocking Primitives, Sleep Queues, and Scheduler Hygiene”
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.
There’s a real disconnect between the code that’s visible and the veteran status that’s claimed. This discrepancy isn’t trivial
Continue Reading “The Pirate Software Paradox: What Happens When Influence Outpaces Skill”
Call me a control freak. But after decades in software development, I’ve learned to be cautious, especially when it comes to building systems on top of third-party APIs. While APIs can offer short-term acceleration, they often introduce long-term fragility that you can’t control. Why Relying on 3rd Party APIs Is Risky Using third-party APIs might
Recent Comments