Forem: Bhushitha Hashan

Stop Wondering How Virtual Memory Works!!!

Bhushitha Hashan — Tue, 07 Apr 2026 05:55:15 +0000

It’s 9:45 PM on a Tuesday. The office lights are dimmed, and the only thing illuminating Arjun’s face is the harsh white glare of a terminal filled with a nasty kernel backtrace. He’s slumped in his chair, hands over his face, looking like he’s about to lose it.

Maya, a Senior SRE who lives off black coffee and complex systems, walks by his desk on her way to the breakroom. She stops, seeing the "I’m fucked" energy radiating off him.

The Scene: Late Night at the SRE Lab

Maya: Yo, Arjun. You still here? You look like you just watched a server rack fall over. What’s up?

Arjun: (Groans) Maya, man... I’m losing my mind. I’ve been trying to debug this C program for four hours. I keep getting a SIGSEGV at an address that looks like 0x0000800000001234. I thought I understood memory, but this just looks like a random number. My pointers are tripping, and I don't even know where this data is actually going.

Maya: (Leans over, looking at the screen) Ah, the classic "I think I know pointers" crisis. Don't sweat it. everyone hits this wall. You’re looking at a virtual address, but you’re stressed because you can’t see the "real" memory, right?

Arjun: Exactly. It feels like magic. I know the CPU does something with page tables and the MMU, but it feels like a black box.

Maya: Alright, pull up a chair. Let’s strip the magic away. Think about it like this: your program is a spoiled brat. It thinks it owns the entire memory space,yes from zero to the max. That’s the Virtual Address Space. But the actual RAM (the Physical Address) is a shared resource the OS manages.

Arjun: So the CPU translates them on the fly?

Maya: Yeah, via the MMU (Memory Management Unit). But it doesn't translate byte by byte.that would be insane. It does it in 4KB chunks called Pages.

Arjun: Okay, so a virtual address is just an index?

Maya: Sort of. Look at your 64-bit address. Even though we call it 64-bit, x86_64 CPUs usually only use 48 bits for addressing right now.

Arjun: Wait, why only 48?

Maya: Because 48 bits gives you 256 Terabytes of RAM. We don't exactly have that sitting in the server room yet. But here’s the kicker: bits 48 through 63 must be a copy of bit 47. If bit 47 is 0, the top bits must be 0. If it's 1, the top bits must be 1. This is called Canonical Form.

Arjun: (Looking at his code) Wait... bit 47 in my address 0x000080... is 0, but bit 48 is a 1.

Maya: Bingo. That’s why you’re fucked. You broke the canonical rule. The CPU didn't even look at the page table; it just saw that bit 48 didn't match bit 47 and threw a General Protection Fault. SIGSEGV. Game over.

Arjun: Holy shit. So the address space is basically split in half?

Maya: Exactly.

Lower half (bit 47=0): User space (0x0000...)
Upper half (bit 47=1): Kernel space (0xffff...) Anything in that "hole" in the middle is radioactive.

Arjun: Okay, so if I fix my pointer math and stay in the lower half, how does it get to the actual RAM chip?

Maya: This is where it gets cool. The MMU takes your virtual address and splits it. The lowest 12 bits (bits 0–11) are the Offset. Since 2 to the power 12 = 4096, that offset points to the exact byte inside a 4KB page. The rest of the bits are the Virtual Page Number (VPN).

Arjun: And the MMU uses that VPN to "walk" the page table?

Maya: Right. It’s a 4 level tree. It’s like a scavenger hunt. The CPU starts at a base address in the CR3 register, uses bits from your address to find the next level, and finally lands on a PTE (Page Table Entry).

Arjun: (Squinting) So the PTE is the final answer?

Maya: Yes, you’ve got it exactly right. But the PTE is a compact little structure, not just a plain address. Look at this:

Bits 0–11: These are your Permission and Status Flags.
Bits 12–51: This is the PFN (Physical Frame Number).
Bit 63: This is the NX (No Execute) bit.

Arjun: Wait, so you’re saying the first 12 bits are just used for permissions and shit, and the other bits do the actual pointing?

Maya: Yes, exactly! The PTE contains the physical frame number (PFN) , which is the real, physical address of the page in RAM, but it's shifted right by 12 bits to save space.

When the CPU confirms you have permission (checking those flags in bits 0-11 like "is it writable?" or "is it user-accessible?"), it takes that PFN, shifts it left by 12 bits (which is just adding twelve zeros at the end) to get the base physical address, and then it adds the offset from your original virtual address.

Arjun: So: Virtual address -> PTE -> PFN (real physical page address) -> + offset -> real physical byte address.

Maya: Exactly. No more indirection. That’s the final translation. The address that comes out of that math is what goes out on the memory bus to actually grab the data from the RAM stick.

Arjun: Man, that bit shifting is clever. It’s like they reused the 12 bits of the offset to store the permissions in the PTE because they knew the physical frame address would always end in twelve zeros anyway.

Maya: Spot on. You’ve mastered the PTE layout. Now, what happens if the Present bit (bit 0) is 0?

Arjun: The MMU can’t find the page?

Maya: Right. Page Fault. The CPU stops what it's doing and screams for the OS. The kernel's page fault handler looks at the CR2 register to see where you were trying to go. If you were just trying to access a page that got swapped to the SSD, the kernel quietly loads it into RAM, updates the PTE, and lets your program continue like nothing happened.

Arjun: But if I’m trying to write to a read-only page or a null pointer?

Maya: Then the kernel realizes you’re doing something illegal and sends you a SIGSEGV. Which is exactly what happened to you tonight.

Arjun: (Laughs) Because I was hitting a non-canonical address. I didn't even make it to the page table check.

Maya: Exactly. And one last thing,don't forget the TLB (Translation Lookaside Buffer). Walking a 4-level page table for every single memory access would make the computer slow as hell. The TLB is a tiny, super fast cache in the CPU that remembers recent "Virtual -> Physical" translations. It's the only reason modern computers are fast.

Arjun: So: Check TLB -> if miss, walk Page Tables -> check PTE flags ->calculate physical address -> fetch data.

Maya: You got it. Now, quit staring at that backtrace, fix your pointer math, and let's get some food. My treat.

Arjun: (Closing the laptop) Thanks, Maya. I actually feel like I know what's happening under the hood now. I’m not just "fucked",I’m "educated and fucked."

Maya: (Laughing) That’s the spirit kid. Let’s go.

Speed vs Truth: Understanding Redis the Way Engineers Actually Do

Bhushitha Hashan — Wed, 18 Mar 2026 16:01:12 +0000

Late Afternoon, Real System, Real Confusion

The office was quieter than usual. Most people had already left, but one corner still had life in it.

A whiteboard covered in boxes, arrows, and half-erased notes.

And in front of it,Arjun.

A few weeks into his internship, he had reached that stage where things no longer looked simple… but also didn’t fully make sense yet.

Behind him, leaning on the desk with a coffee mug that had clearly been refilled too many times, stood Maya,the senior systems engineer.

She watched him stare at the diagram for a while before speaking.

“Alright,” she said, calm and direct. “You’ve been staring at that same box for five minutes. What’s bothering you?”

Arjun didn’t turn immediately. He pointed at the whiteboard.

A box labeled:

Redis

“I get that this is for speed,” he said slowly. “Like… we put it in front of the database so things don’t get slow.”

Maya nodded. “Good. That’s the surface-level answer. Keep going.”

Arjun hesitated, then turned.

“But it feels… fake.”

Maya raised an eyebrow. “Fake?”

“Yeah,” he said. “Like it’s not real storage. It’s just… temporary. So why are we trusting it at all?”

Maya smiled.

“Good,” she said. “Now we can actually start.”

What Redis Actually Is (Explained Like You Mean It)

Maya walked to the whiteboard and drew two boxes.

[ Redis ] -------- [ Database ]
   (RAM)             (Disk)

She tapped the first box.

“Redis lives in memory. RAM. That’s why it’s fast.”

Then she tapped the second.

“The database lives on disk. That’s why it’s slower,but reliable.”

Arjun nodded. “Yeah, I get that part.”

“No,” Maya said, shaking her head slightly. “You understand the words. Not the implication.”

She turned back and wrote:

Redis = Speed, Not Permanence

“Everything about Redis is optimized for one thing.responding fast,” she continued. “Not guaranteeing your data will exist forever.”

Arjun frowned slightly. “So… it can lose data?”

“It will lose data,” Maya corrected.

She started listing on the board:

Memory limit → eviction
Crash → possible data loss
Restart → partial recovery

Then she turned.

“So if you think of Redis as your database, you’ve already made a mistake.”

The First Mental Breakthrough

Arjun crossed his arms, thinking.

“So then what is it actually?”

Maya didn’t answer immediately. Instead, she erased a small section and drew this:

User → App → Redis → Database

“Most requests stop here,” she said, pointing to Redis.

Then she added:

User → App → Redis ❌ (miss) → Database → Redis → User

“This is what happens when Redis doesn’t have the data.”

She stepped back.

“Redis is not the source of truth,” she said.
“It’s a temporary, fast copy of reality.”

Arjun repeated it quietly.

“…temporary copy.”

“Exactly.”

Why We Even Need Redis

Arjun turned back to the board.

“Okay, but why not just make the database faster?”

Maya laughed softly.

“Everyone asks that at some point.”

She drew two timelines.

RAM access  → nanoseconds
Disk access → milliseconds

Then she circled them.

“This difference is massive,” she said. “You don’t ‘optimize’ your way out of physics.”

She drew another diagram:

Without Redis:
User → App → Database (every request)

Then:

With Redis:
User → App → Redis (most requests)
                ↓
             Database (rare)

“Redis exists so your database doesn’t collapse under load.”

Where Things Start Getting Dangerous

Arjun nodded, following along.

“Okay… so we cache stuff. Makes sense.”

Maya tilted her head slightly.

“That works when data doesn’t change often,” she said. “But what about things that change constantly?”

She wrote:

page views
likes
active users

Then added:

“Where do those updates happen?”

Arjun answered quickly.

“In Redis… because it’s fast.”

Maya nodded.

“And now you’ve just moved the problem.”

The Fear Kicks In

She wrote on the board:

views:article:123 → 10,482

“This number keeps increasing,” she said.

Arjun nodded.

Then she asked:

“What happens if Redis runs out of memory?”

Arjun paused.

“…it deletes something?”

“Yes.”

“And if that key gets deleted?”

“…we lose the count.”

Maya crossed her arms.

“Now you see the problem.”

The Second Mental Shift: Not All Data Is Equal

Arjun leaned back slightly.

“So we shouldn’t store important stuff there.”

“Exactly,” Maya said. “But let’s define ‘important’ properly.”

She split the board into two sections.

Left Side

Critical Data

payments
orders
balances

She underlined it.

“Lose this, and your system is broken.”

Right Side

High-Speed Data

analytics
counters
sessions

“Lose a bit of this?” she shrugged. “System still works.”

“Now the rules change,” she said.

Two Ways to Write Data

Maya drew two flows.

1. Write-Through

App → Database → Redis

“Safe,” she said. “Slower, but correct.”

2. Write-Behind

App → Redis → (later) Database

“Fast,” she said. “But risky.”

Arjun looked at both.

“So we just pick one?”

Maya shook her head.

“No. We use both. Based on the data.”

The Trade-Off Nobody Escapes

She turned to him.

“You can’t have perfect speed and perfect safety at the same time.”

Arjun nodded slowly.

“Yeah… that makes sense.”

The Data Loss Gap (This One Matters)

Maya drew a timeline.

Time →
[ Redis updated ] ---- (delay) ---- [ DB updated ]

“This gap,” she said, tapping the space in between, “is where things can go wrong.”

Arjun leaned forward.

“If the system crashes there…”

“…you lose data,” Maya finished.

So We Add a Queue

She erased part of the board and drew a new flow:

App:
  → Update Redis
  → Push event → Queue

Then:

Worker:
  → Read Queue
  → Update Database

Arjun looked at it.

“So now even if Redis crashes…”

“The queue still has the data,” Maya said.

“And if the worker crashes?”

“It resumes from the queue.”

Arjun nodded.

“…okay, that’s solid.”

When Things Go Wrong (And They Will)

Maya didn’t respond immediately.

Instead, she tilted her head slightly.

“Solid… but not perfect,” she said.

Arjun frowned. “What do you mean?”

“Walk it through again,” Maya said.

Arjun looked back at the board.

“Okay… we write to Redis, push to the queue…”

He paused.

“What if Redis evicts the key before the worker runs?”

Maya nodded. “Keep going.”

“And then… what if the worker fails before writing to the database?”

Now he stopped completely.

“…then the data never reaches the database.”

Maya crossed her arms.

“And Redis already lost it.”

They both looked at the board.

“So we still lose data,” Arjun said quietly.

“Exactly.”

Maya uncapped the marker again.

She drew it out slowly.

1. Write → Redis
2. Push → Queue
3. Redis evicts key ❌
4. Worker fails ❌
5. Data never reaches DB

She stepped back.

“This,” she said, “is the kind of failure that doesn’t crash your system.”

Arjun frowned.

“…it just loses data.”

“Exactly.”

The Subtle Problem With “Safe Enough”

Maya crossed her arms.

“The queue reduces risk,” she said. “But it doesn’t eliminate it.”

Arjun nodded slowly.

“So what do we do?”

Three Things Real Systems Add

Maya held up three fingers.

“Once you reach this level, you start thinking about three things.”

1. Idempotent Writes

“If the worker retries the same update twice,” she said, “nothing should break.”

She wrote:

Bad:
INCR views → duplicates possible

Better:
SET views = value with version

“You design your writes so repeating them is safe.”

2. Assume the Queue Lies

Arjun blinked. “The queue… lies?”

Maya smiled slightly.

“Not maliciously. But it might deliver the same message twice. Or later than expected.”

She underlined it.

Always assume at-least-once delivery

“Your system must handle duplicates.”

3. Retry Properly

“What if the worker fails?” she continued.

“Retry?” Arjun said.

“Yes. But not blindly.”

She wrote:

Retry with delay
Exponential backoff
Dead-letter queue (failed forever)

“If you don’t handle failures properly,” she said, “they disappear quietly.”

The Final Realization

Arjun leaned back.

“So even the ‘safe’ design isn’t actually safe.”

Maya nodded.

“Nothing is perfectly safe,” she said. “You just keep reducing risk.”

Updating the Mental Model

Maya walked back to the board one last time and added a small note next to the system:

[ Redis ] → fast but fragile  
[ Queue ] → safer, but needs retries  
[ Database ] → final truth

Then underneath it, she wrote:

Design for failure, not success

Arjun stared at the board.

“…this got complicated fast.”

“Yeah,” she said. “Welcome to distributed systems.”

But There’s Still a Subtle Problem

Maya smiled slightly.

“But There’s always one more problem.”

She drew:

1. Redis loses key
2. User requests data
3. App checks DB
4. DB is slightly outdated

Arjun’s eyes narrowed.

“So the user sees old data.”

“Exactly.”

Read Repair (The Quiet Fix)

Maya added one more layer:

Cache miss →
  Fetch DB →
  Check queue →
  Merge updates →
  Return →
  Update Redis

Arjun blinked.

“So reading actually fixes the data?”

“Yep.”

Everything Comes Together

Maya stepped back and rewrote the system cleanly:

          [ Redis ]
              ↓
User → App → Cache Layer
              ↓
          [ Queue ]
              ↓
          [ Database ]

She pointed at each part.

“Redis gives you speed.”

“Queue gives you safety.”

“Database gives you truth.”

The Final Understanding

Arjun looked at the board for a long moment.

Then he said quietly:

“So Redis isn’t the system.”

Maya smiled.

“It’s part of the system.”

He nodded.

“And the database…”

“…is reality,” she finished.

The One Sentence That Matters

Maya picked up the marker one last time and wrote:

Move fast in Redis, commit safely through queues, trust the database.

Arjun read it once.

Then again.

This time, the diagram didn’t feel confusing.

It felt… inevitable.

If You Walk Away Remembering This

Maya capped the marker and turned.

“Before you leave,” she said, “tell me what you learned.”

Arjun didn’t hesitate this time.

Redis is fast but temporary
Data there can disappear
Important data goes to the database first, then update Redis
Fast changing data can go to Redis first with a queue
Queues make things safer, but not perfect
Everything is a trade off

Maya nodded.

“Good. Now you’re not just using Redis anymore.”

Arjun looked back at the board one last time.

“It’s not just about making it fast,” he said.

Maya shook her head slightly.

“It’s about knowing where it can break.”

She picked up her coffee.

“That’s when you start thinking like a systems engineer.”

A Deep Dive into Kernel Context Switching

Bhushitha Hashan — Fri, 06 Mar 2026 15:02:41 +0000

The afternoon sun was hitting the glass. Marcus, a senior engineer who had seen more kernel panics than he had hot meals, sat leaning back in his chair. Opposite him, Leo, the new intern, was staring intensely at a series of assembly snippets on his dual-monitor setup.

"Marcus," Leo said, spinning around. "I’m looking at how Linux handles processes. I get the theory, but the hardware part feels like magic. There’s no task_struct_ptr register on an x86 CPU. So how does the kernel actually know who it is the millisecond a system call happens?"

Marcus grinned. "You’ve hit the 'GPS' problem of OS design. Pull up a chair. You have to understand that the CPU is a bit of a blank slate; the OS has to carve its own landmarks into the hardware."

Why the GS Register is the Kernel’s North Star

"To answer your question," Marcus began, "we have to talk about the GS register. In the world of x86_64, OS designers decided that general-purpose registers like RAX or RBX were too precious to waste. If you used RBX to hold the pointer to the current task, you’d have one less register for math in every single function. Plus, if a programmer accidentally overwrote it, the system would forget which task was running and crash immediately."

He pointed to Leo’s screen. "Instead, Linux uses the GS register as a stable anchor. It’s reserved specifically to point to Per-CPU Data. Each CPU core has its own GS base address that points to a private memory area for that specific core."

The Transition: From User to Kernel

"When you’re in User Mode," Marcus continued, "the GS register might be used for thread-local storage. But the moment a system call or an interrupt happens, the CPU executes a specialized instruction called swapgs. This instruction flips the GS base to a kernel-specific area. Inside that area, the kernel stores the most important information: the Task Struct and the Kernel Stack."

"So it's like a 'GPS Home' button?" Leo asked.

"Exactly. When the kernel code needs to know 'Who am I?', it doesn't search a list. It just executes something like mov rax, gs:[offset_of_current_task]. It’s a direct, protected lookup."

Entry and the Trap Frame

"But before the kernel even thinks about switching tasks," Marcus said, "it has to protect the current one. The moment a user program triggers a syscall or an interrupt, the CPU executes swapgs. This flips the GS base to the kernel’s side. But then, the kernel performs its first vital ritual: Saving the User State."

"Wait, so it doesn't just jump into kernel code?" Leo asked.

"Not without a backup. The kernel immediately pushes all the user's current registers—RAX, R11, RCX, and the rest—onto the kernel stack. This collection is called the Trap Frame (or pt_regs). This ensures that no matter what the kernel does next, it has a perfect 'save-point' of exactly what the user was doing. Without this step, we could never return to the application."

The RSP Dillema

"Wait,What happened to the user stack pointer ?Do we just save it too while switching?" leo asked.Marcus leaned back, laughing softly. "That’s the exact question that keeps kernel developers up at night. You're thinking about the 'Exit'the popping. But the problem is the 'Entrance'. It’s a game of musical chairs where the CPU only has one seat, and that seat is the RSP register."

He grabbed a dry erase marker and drew a single box on the board labeled RSP.

"Here is your problem, Leo, The RSP register can only hold one address at a time. It’s either pointing at the User Stack or the Kernel Stack. It cannot point to both."

The "One-Handed" Problem

"Imagine you are holding a priceless Ming vase.that's the User Stack Pointer," Marcus said, gesturing with his hands. "You need to put it into a safety deposit box.that's the Kernel Stack. But the only way to open the safety deposit box is to use the same hand that is currently holding the vase."

"The moment you reach for the box (the Kernel Stack), you have to let go of the vase (the User Stack Pointer). If you let go, it smashes on the floor. You've lost it."

The "Stash" Before the "Push"

"To get that User RSP value into the pt_regs struct on the kernel stack, you have to perform a very specific sequence of moves. Watch the registers closely:"

The Entry: You just hit syscall. RSP is currently holding the User Stack address.

The Dilemma: You need to change RSP to point to the Kernel Stack so you can start pushing pt_regs.

The Move: But if you just do mov rsp, gs:[top_of_stack], the User Stack address is gone. It’s overwritten in the register. You can't 'push' it later because you don't know what it was anymore.

"This is why we use gs:[user_stack_ptr] as a temporary shelf," Marcus explained.

"The kernel executes:

mov gs:[user_stack_ptr], rsp (Putting the vase on the shelf)

mov rsp, gs:top_of_stack

Now that RSP is safely pointing to the Kernel Stack, the kernel can finally do the 'Push' you’re talking about:

push gs:user_stack_ptr"

"Can't we just pop?"

"You're right about the end of the story," Marcus nodded. "When the system call is over, we do pop the registers from the pt_regs back into the CPU. But you can't pop something that was never pushed. And you can't push the User RSP unless you have a temporary place to hold it while you're switching the RSP register itself."

Leo stared at the whiteboard. "So it's literally just a bridge? A place to hold the value for, like, three instructions?"

"Exactly," Marcus said. "It’s a 'scratchpad.' Once the User RSP is safely pushed into the pt_regs structure on the kernel stack, the value sitting in pcpu_hot.user_stack_ptr isn't actually used for much else until the next time that CPU core handles a transition. It's the only way to 'teleport' the stack pointer from a register to a memory location without losing it in the process."

"Why not use a general register like RAX?"You might ask: 'Why not just move RSP into RAX temporarily?'" Marcus anticipated the next question. "Because RAX is a User Register. It contains the System Call Number (like 1 for write or 0 for read). If you move the stack pointer into RAX, you just deleted the user's instructions on what they wanted the kernel to do!"

"The GS-based memory is the only place in the entire universe the kernel can 100% trust to be 'clean' and available the moment a syscall starts."

Marcus tossed the marker back onto the tray. "It’s all about that tiny window of time where the CPU is 'homeless' between stacks. user_stack_ptr is the kernel’s temporary roof."

The Great Teleportation: Updating the Identity

Leo tapped his pen. "Okay, so we’ve saved the user registers. Now the scheduler wants to move from Task A to Task B. How does the GS area know Task B is the new king?"

"This is the crucial part people often miss," Marcus said. "The scheduler doesn't just swap the stack; it has to re-program the identity of that CPU core. Inside the context switch function, the kernel physically overwrites the memory inside the Per-CPU area.

It takes Task B’s task_struct address and writes it into gs:[offset_of_current_task]. Then, it takes Task B’s kernel stack pointer and writes it into gs:[offset_to_top_of_stack].

Crucially, we don't change the GS Base address itself,that still points to the same CPU core. We just update the 'data' inside that core's private office. Once those pointers are updated, any part of the kernel that asks 'Who is the current task?' will now get Task B as the answer."

The Performance Shortcut: Beating the Memory Latency

Leo frowned, tapping his pen. "Wait. If the kernel has to find the gs base, then find the task_struct, then find the pointer to the stack inside that struct... isn't that a lot of memory hopping? That sounds slow for something that happens thousands of times a second."

"You’re right," Marcus nodded. "That's a classic bottleneck. Modern Linux engineers hate extra memory hops. To fix this, they use redundancy for speed. They don't go to the task_struct every time they need the stack."

"Inside that Per-CPU area pointed to by GS, there's a structure—often called pcpu_hot. The kernel stores a direct copy of the 'top of the stack' right there, just bytes away from the task pointer.

When a syscall triggers:

The CPU is still on the User Stack (RSP).
The kernel runs swapgs.
It immediately executes mov rsp, gs:[0x00] (or whatever the stack shortcut offset is).

In one instruction, the kernel is on the correct stack. It never even had to touch the task_struct to find it. Because this data is accessed constantly, it almost always lives in the L1 Cache. It’s nearly as fast as a physical register."

The Great Teleportation: How Context Switching Actually Works

"Okay," Leo said, leaning in. "So we have the pointers. But how does the scheduler actually stop Task A and start Task B? How does Task B know where it left off?"

Marcus cleared his throat, warming up to the narrative. "This is the 'Save Game' trick. Think of a context switch as a 'handover.' When the scheduler decides to switch, it calls a function named __switch_to(). This is where the magic happens."

1. Freezing Task A

Before Task A is moved aside, the kernel must 'freeze' its state. It pushes the current registers—RBX, RBP, and others onto Task A's own kernel stack. The very last thing it does is save the current RSP (the stack pointer) into Task A's task_struct.

2. The RSP Swap

"Now comes the moment of teleportation," Marcus said, mimicking a switch flip with his hand. "The scheduler loads the address of Task B. It takes the stack pointer that Task B saved the last time it was frozen and moves it into the actual RSP register."

# rax = Task B's task_struct
mov rsp, [rax + stack_offset]  # THE SWITCH: rsp now points to Task B's stack!

"The second that instruction executes, the CPU is no longer looking at Task A’s history. It is looking at Task B’s stack."

The Layered Timeline: Why the Stack is a Time Machine

Leo looked puzzled. "But how does Task B know what to do next? Does the scheduler have to jump to a specific instruction?"

"That’s the beauty of it," Marcus replied. "The scheduler doesn't 'jump.' It returns. You see, every task follows the same ritual to go to sleep, so they all know how to wake up. A task’s kernel stack is a perfectly preserved timeline with two layers."

The Two Layers:

Layer 1 (The Trap Frame): This is the User State. It’s at the very bottom of the stack. It contains the User RIP (where the app was in its own code) and the User RSP.
Layer 2 (The Context): This is the Kernel State. It contains the registers the task was using inside the kernel just before it was switched out.

"Because the stack is First-In, Last-Out (FILO), the task just travels backward through its own history.

It pops the kernel registers (restoring its 'Kernel Self').
It executes the ret instruction.

Now, here is the secret: The ret instruction pops the top value of the stack into the RIP (Instruction Pointer). Since Task B was frozen during a function call, the top of its stack contains the 'return address',the exact line of code following the switch. It literally 'returns' into its own past."

The Final Piece: The Kernel RIP

"Wait," Leo interrupted, "so the Kernel RIP is never explicitly saved with a mov command?"

"Exactly!" Marcus clapped his hands. "When the code calls __switch_to, the call instruction automatically pushes the next RIP onto the stack as a bookmark. Then, when the task wakes up later and hits ret, it simply picks up that bookmark and continues.

Once the kernel finishes its work, it executes a final sysret or iretq. This pops Layer 1,the Trap Frame.restoring the original User RIP and RSP. The CPU is suddenly back in the user application, exactly where it left off, unaware that it was ever frozen."

Marcus stood up and headed toward the coffee machine. "The stack isn't just memory, Leo. It’s a timeline. As long as you keep the RSP and the GS base pointed at the right spots, the CPU will always know exactly who it is and what it was doing."

Leo turned back to his monitors, the assembly code finally looking less like a wall of text and more like a carefully choreographed dance.

The Blueprint: `struct pcpu_hot`

In modern kernels, it looks like this. Notice how current_task and top_of_stack are right at the top for maximum speed."

struct pcpu_hot {
    union {
        struct {
            /* The current running task_struct */
            struct task_struct  *current_task;

            /* The top of the kernel stack for the current task */
            unsigned long       top_of_stack;

            /* Used for user/kernel transition (GS base swap) */
            unsigned long       user_stack_ptr;

            /* ... other high-frequency data ... */
        };
        u8  pad[64]; /* Padded to a full cache line */
    };
};

SLIs, SLOs, SLAs: The Guide to SRE’s Secret Sauce

Bhushitha Hashan — Wed, 11 Feb 2026 01:53:56 +0000

If you ever wanna be an SRE, a real site reliability wizard, you gotta speak the language of the freakin’ trade. And that language? It ain’t “install Prometheus” or “deploy Kubernetes.” Nah, bro. It’s SLIs, SLOs, SLAs, and Error Budgets.The holy trinity of keeping shit alive and your boss off your ass.

This is how real humans measure reliability, and if you don’t get it, you’re just another person staring at CPU graphs wondering why the feed is broken.

SLIs : Service Level Indicators: The User’s Reality Check

SLI is like your street-level gossip. It tells you how your service is actually behaving from the user’s point of view, not from some nerdy server graph.

Examples in tech-world:

How fast does your social media feed load for a user? That’s your latency SLI.
How many posts fail to load or error out? That’s your error rate SLI.
How often is your API completely unavailable? That’s your availability SLI.

Notice something? Users don’t give a flying fuck about CPU load, memory usage, or thread pools. That shit is irrelevant. SLIs are the numbers that matter to humans. They’re your reality check.

Think of SLIs as the pulse of your service. When the pulse drops, shit’s about to hit the fan.

SLOs: The Chill Target You Actually Give a Damn About

SLO stands for Service Level Objective, but don’t get stuck on words. Think of it as the promise you make to yourself about what’s acceptable.

Examples distributed here:

99.9% of requests to your checkout API should complete in under 500ms.
99% of posts in the social media feed should load correctly on the first try.

That’s not perfection. That’s “good enough”, and here’s the kicker: perfect is stupidly expensive. Trying to hit 100% uptime is like promising every post loads instantly no matter the traffic spike. Chill. Nobody cares about perfection; SREs care about manageable reliability.

SLAs: The Contract With Your Customers (aka The Lawyers Show Up)

SLAs are where shit gets legal. Service Level Agreement. It’s what you promise to your paying users, and if you fail, they can demand refunds or penalties.

Examples distributed here:

“If checkout API availability drops below 99.5% in a month, we refund the transaction fee.”
“If social media feed errors exceed 0.5% for the month, we compensate premium users.”

SLAs are basically the adult version of your SLOs, but now lawyers are watching. Your internal metrics (SLIs, SLOs) are tools to avoid SLA violations.

Error Budget: How Much Failure is Allowed

Here’s where the genius of SRE shines. Every SLO comes with an error budget.

Example: Your SLO says 99.9% of checkout requests < 500ms. That means 0.1% of requests can fail before you’re in trouble. That 0.1% is your error budget.

Error budgets aren’t just numbers,they are decision-making tools:

Hit your error budget? Stop risky deployments. Calm the hell down.
Well within your error budget? Go ahead, push that new feature. Risk it, baby.

Error budgets let you balance velocity with reliability. You stop firefighting everything, and you start deploying smartly.

Analogy: Think Like the User, Not the Server

Here’s the core truth:

SLI = how fucked is it right now?
Users care about feed failing, checkout slowing, API errors. That’s your SLI.
SLO = how fucked is okay?
“I can survive a few mistakes.” Maybe 1 in 1,000 API requests fail. That’s your SLO.
Error Budget = how much failure I can tolerate before flipping out
If you exceed it, shit hits the fan internally.
SLA = how much messing arround can I get sued?
Customers will hammer you legally if you break it. That’s your SLA.

Why You Give a Damn as an SRE

You measure first, fix second.
You don’t chase metrics that users can’t feel. CPU spikes are irrelevant. Latency and error rates are everything.
You accept failures. Shit breaks, but you have an error budget to survive and deploy fast.
You automate prevention, because repeating firefighting is for suckers.

Linux Privileges:Peeling Back the Curtain Of How Linux Really Handles Users, Privileges, and Processes

Bhushitha Hashan — Fri, 06 Feb 2026 06:54:57 +0000

Introduction

On how Linux really handle privileges on processes has always felt like a black box to me. You type a command, and sometimes the system says “permission denied,” sometimes “okay, you’re root now,” and you shrug. You think it’s magic. But today, after spending hours staring into /proc, reading task_struct, tracing execve(), and watching UIDs dance around, I finally see what’s really happening. Linux isn’t magic at all it’s mechanical, almost brutally logical.simple yet powerfull and perfect. Every privilege, every setuid program, every sudo call, every login shell is enforced in code. No luck, no wizardry just a lot of careful kernel work.

I’m going to break it all down. Strap in.

UIDs: The Kernel Doesn’t Give a Damn About Names

Okay, now, let me catch your thought: “wait, but what about /etc/passwd and usernames?” Yeah, I get you. That’s the trap most people fall into. The kernel does not care about your username. Zero. The kernel only cares about numbers: UIDs and GIDs. That’s it.

Every process has a task_struct. Inside that is a cred struct that tracks all the UIDs and GIDs relevant to the process:

struct cred {
    kuid_t ruid;  // Real UID: the user who launched the process
    kuid_t euid;  // Effective UID: what you can actually do right now
    kuid_t suid;  // Saved UID: what you can regain if you drop privileges temporarily
    kgid_t rgid;  // Real GID
    kgid_t egid;  // Effective GID
    kgid_t sgid;  // Saved GID
};

ruid (Real UID): Think of it like your “birth certificate” in Linux.its who spawned you. This almost never changes unless a privileged syscall explicitly allows it.
euid (Effective UID): This is what the kernel actually checks for privileges. Want to open /etc/shadow? Kernel checks this. Want to bind port 80? Kernel checks this.
suid (Saved UID): This is your “back door” to regain privileges you temporarily dropped. I’ll show why this matters with setuid programs.

Rule: The kernel is the boss. Userspace tools like sudo or su just orchestrate things.the kernel is the one making all the actual decisions.

Setuid: Privilege Already Baked Before You Touch Anything

Next up, the setuid. That infamous +s bit. This is literally the kernel saying:

“When this program runs, I’m going to temporarily treat it as if it belongs to the file owner, not the person executing it.”

Let me break it down. You have /usr/bin/passwd (owned by root, setuid). When alice runs it:

ruid = 1000 (alice)
euid = 0    (root)
suid = 0    (root)

Now, look closely:

ruid stays alice —> she is still herself.
euid is root —> kernel checks this for every privileged syscall.
suid is root —> the “return ticket” if alice temporarily drops privileges.

Yes, the saved UID exists because without it, once you drop privileges, you could never regain them. That’s the entire point.

Dropping and Regaining Privileges Safely

Setuid programs don’t just run full power the entire time cause that would be insane. They often drop privileges temporarily while doing risky stuff. Then, when needed, they regain them:

seteuid(ruid); // drop privileges
// do unprivileged work
seteuid(suid); // regain privileges

Timeline (simplified):

Execve setuid-root:
ruid=alice  euid=root  suid=root

Drop privileges:
seteuid(ruid)
ruid=alice  euid=alice  suid=root

Regain privileges:
seteuid(suid)
ruid=alice  euid=root  suid=root

Notice that suid never changes when you temporarily switch euid. It’s a fixed “return ticket.”

When Setuid Is Not Set

Now, let’s be clear: if a file doesn’t have +s, the kernel does something simple:

ruid = caller UID
euid = caller UID
suid = caller UID

Nothing magical. You can’t elevate yourself arbitrarily. Only root (or a setuid-root binary) can raise privileges.

Rules of Privilege Escalation

Now, now, I know what you’re thinking: “so, only root can become anyone else, right?” Exactly. Let’s spell it out:

euid=0 (root): can change ruid/euid/suid to anything. Full control.
Normal users: can only lower privileges (drop euid). No raising to someone else’s UID.
Setuid files: allow a controlled, kernel-enforced elevation to the file owner’s UID.
ruid: almost immutable; it’s your original identity.

Example scenario:

User1: UID 1001
User2: UID 1002

User1 cannot become 1002.
User2 cannot become 1001.
Only root could switch to either.

Login Shells and TTYs: The “Fall From Grace”

Alright, now I know exactly what you’re thinking if u read it till now,: “if the ruid is the one who start the process,who the hell owns the TTY I log in to?” Let me untangle this.

Before you log in, every virtual terminal (VTY) is essentially owned by root. That’s right,before login, you are like an all-powerful god sitting in /dev/tty1…6.

Then systemd or init starts getty (or agetty), which listens for login attempts. getty itself is root-owned. it has to be, because it’s going to spawn login shells, check passwords, and eventually drop privileges safely.

When you finally log in:

login verifies your credentials
then spawns your login shell (bash, zsh, whatever)
and suddenly you fall from grace:

ruid = your UID
euid = your UID
suid = your UID

Haha, right? All-powerful god → mortal user in one instant. This is why root privileges are tightly controlled: you can’t just pick up random UIDs at will. The kernel enforces this rigorously.
here check this image ive attached below if u still find this tty thing confusing..

`sudo`, `su`, and Variants

Here’s the part most people misunderstand: sudo and su aren’t magical at all they’re setuid-root programs that orchestrate privilege elevation under kernel rules.

sudo: Runs as root (setuid), checks /etc/sudoers, then temporarily switches euid to root for your command.
sudo -i: Starts an interactive root shell (euid=0).
su: Switch user; requires root privileges to switch to another user.
su -: Switch user and simulate login environment (PATH, environment variables, etc.).

Without the kernel enforcing UIDs, all of this would be meaningless. When you run sudo, the kernel sees:

ruid = original user
euid = root (because sudo binary is setuid-root)
suid = root

And everything is checked at the syscall level. Permissions aren’t faked.they are real.

Process Startup: Everything Happens in Order

Timeline, kernel-first:

Parent calls execve(path, argv, envp)
    ↓
Kernel checks permissions, filesystem flags, LSM
    ↓
Kernel sets credentials (ruid, euid, suid) → includes setuid handling
    ↓
Kernel loads ELF segments into memory
    ↓
Kernel builds stack with argc, argv, envp, auxv
    ↓
Kernel switches to user mode at _start
    ↓
C runtime extracts argc, argv, envp
    ↓
main(argc, argv, envp) runs

Key point: credentials are applied before the environment exists, before the program executes a single instruction, and before it can touch syscalls. That’s why setuid works safely.

Mental Model

Think of Linux privileges like this:

execve()          → kernel enforces creds (ruid/euid/suid)
   ↓
ELF loaded, stack built (argc/argv/envp)
   ↓
_enter_user_mode()
   ↓
C runtime sets up main()
   ↓
program executes, syscalls checked against euid

Setuid program: ruid = caller, euid = file owner, suid = file owner
Normal program: ruid = euid = suid = caller
Drop privileges temporarily → regain via suid → safe privilege handling
Only root or setuid-root binaries can elevate euid arbitrarily

Why This Matters

Once you understand this:

sudo, su, login shells, daemons, and setuid-root programs stop being mysterious.
Everything funnels down to kernel-enforced credentials.
Understanding ruid/euid/suid, setuid, and process startup explains why Linux is secure and why miswritten setuid programs are a security nightmare.

Linux isn’t magic. It’s just mechanical, precise, and enforced at every step. Once you see it, everything clicks.

Wild Ride from Raw Syscalls to Figuring Out NSS and libc

Bhushitha Hashan — Wed, 04 Feb 2026 07:27:24 +0000

Man, I’ve always had this nerdy obsession with Linux. From day one, I was diving headfirst into the kernel, writing tiny tools using raw syscalls,basically skipping libc entirely and talking to the kernel like a badass. I made my own headers, wrote my own print routines, opened directories using getdents64, parsed /proc for processes… basically living dangerously in the kernel’s backyard.

At the time, I thought I was the shit doing everything “the real way.” And yeah, it worked. But what I didn’t realize was that I was skipping a whole layer of sanity that exists in libc. I had no idea about all the stuff it actually does. All the buffering, human-readable formatting, and things that make life not completely painful.

That WTF Moment: `/etc/nsswitch.conf`

Everything hit me when I stumbled upon /etc/nsswitch.conf while poking around network and user stuff. I opened it and literally went:

“What the actual hell is this? Who the fuck uses this? Isn’t the kernel supposed to know this?”

It was super confusing. I was in full raw syscall mode, so the idea that some config file could tell libc how to handle getpwnam() or getaddrinfo() blew my mind. I had no clue why this “signboard” was even necessary.

Okay, Now NSS Makes Sense

Turns out, NSS = Name Service Switch. And yeah, it’s basically a signboard inside libc telling it where the hell to look for information.

When a program calls something like getpwuid() or getpwnam(), it’s asking:

“Who is this user? What’s their username?”

Here’s the thing: the kernel doesn’t know usernames, it only knows numeric IDs, like UID = 1000. That’s where libc + NSS swoop in like superheroes.

How It Actually Works

Say you call getpwnam("Deadpool"). libc does this:

1.Read /etc/nsswitch.conf

Finds the line for users:
```
 passwd: files systemd
```
This basically says:
- First, check local files (/etc/passwd)
- Then, ask systemd’s dynamic user database

2.Call each NSS module in order

First: libnss_files.so.2 → looks in /etc/passwd
- Found? Cool → return result
- Not found? Keep going
Second: libnss_systemd.so.2 → ask systemd
- Found? Sweet → return result
- Not? Continue to next source if any

3.Return a struct passwd to your program

Full info: username, UID, GID, home dir, shell, all the juicy stuff

Important: NSS itself is not a running program, just a config file + shared libraries. libc calls them dynamically, no extra processes involved.

The Secret Sauce: libc Beyond Raw Syscalls

Here’s something I didn’t realize at first: libc is more than just a syscall wrapper. Sure, it wraps syscalls like write, read, open, getpid, etc., but it also adds a ton of extra sauce:

Buffering and formatting: printf, fopen buffers, getline, etc.
Memory management: malloc, free
Threading support: pthread_* functions
Policy and lookup logic: NSS modules, locale, hostname resolution

Without NSS, this extra sauce works partially:

Syscalls themselves still happen correctly (you can open files, read directories, write to stdout)
Buffering, formatting, memory, threading still works
But any function that needs human-readable names (users, groups, hosts, services) would fail or return NULL, because libc has no map to tell it where to look

NSS Modules Still Use Syscalls Under the Hood

Here’s the other thing that clicked the perfect image on my mind: even NSS modules themselves ultimately use syscalls.

For example, libnss_files.so.2 reads /etc/passwd using open, read, close (syscalls).
libnss_systemd.so.2 talks to the systemd service using IPC syscalls.
So everything still hits the kernel eventually the NSS just adds a layer of logic so libc knows where and how to get the data.

Basically, libc + NSS = fancy middleware. Raw syscalls = truth. NSS just gives meaning to that truth and ensures humans don’t see useless numbers.

How This Hit Me

Before this epiphany, my tools were like:

Open directories with getdents64
Read /proc/<pid>/status → get numeric UIDs
Display numbers only

Which is perfectly fine if you just want raw truth. But it’s boring for humans. Humans want:

PID: 742   User: Deadpool   Process: bash

Not:

PID: 742   UID: 1000   Process: bash

NSS basically translates truth into meaning, and it’s libc that does all the heavy lifting.

Layers of the System (Mental Picture)

Here’s how it finally clicked for me:

Some key nuggets I learned:

libc does way more than syscalls its buffering, formatting, threading, memory, and yes, NSS
NSS is optional if you only need numbers, but humans will hate your output
Systemd has a dynamic user database for service and container users, which NSS can query
Raw syscalls = truth, NSS = meaning

My Reflection

Real talk: this was a big “oh shit” moment. I realized that all my badass low level tools were cool, but they weren’t really “user-friendly” or system aware. I had been skipping an entire ecosystem of userspace logic.

Now, I see the value in combining both:

Raw syscalls → to understand the kernel and ABIs like a boss
libc + NSS → to make tools that are readable, robust, and actually useful

The One-Liner to Finalize It

“Syscalls give you the raw truth; NSS gives libc the damn map to turn that truth into something humans can actually understand.”

This journey taught me not just how Linux works, but also how to think in layers: kernel, ABI, libc, NSS, and human-readable output.

And now, whenever I build a tool, I don’t just make it work, I know why it works, what layer is doing what, and how the pieces actually fit together.

API Demystified: From Confusion to Confidence

Bhushitha Hashan — Sat, 30 Aug 2025 08:17:30 +0000

Ok today let’s talk about API. what the fuck is it, what makes a good API, and why APIs have become such a hot topic that even non-tech folks have to care about it.

so when i first came across the word API, it felt like some weird nuance.I kinda knew what it was, but if someone actually asked me “what’s an API?” … bruh, i’d stumble. yeah i could spit out an answer, but it didn’t feel like it came from me. i wasn’t confident, i wasn’t comfortable.

and if you feel the same, if you’re not fully comfy around APIs,then this one’s for you.

what even is an API?

first things first: when we google or ask around, answers about APIs sound different. some say “it’s a well-defined interface where two software applications talk to each other.” others say “it’s a contract, not just technology.”

so… who’s right? actually both.

umm, how do i paint this picture so it sticks?

right!! imagine going to a restaurant. you get a menu. now, this menu shows you exactly what you can order. you can’t just order stuff outside of it. this is like a well-defined interface: you’re shown your options, you don’t need to run into the kitchen asking around. the menu already gives you the “what’s possible.”

now, when you order pasta, you expect pasta. if the waiter brings you rice and curry? chaos. you’d be confused, maybe pissed.

see the parallel? the restaurant gave us a menu aka the API. the menu tells us what’s possible and what we can expect. and we as customers expect the restaurant to actually deliver what we asked for. that’s the contract.

so yeah..an API is both things: a well-defined interface and a contract between provider and receiver. a good API checks both boxes.

ok, cool now, but what makes an API “good”?

now you got the picture of what an api is. not super detailed yet, but enough of a mental image to explore deeper.

and here’s where people usually stumble: most of us aren’t actually designing APIs, we’re just using them. when we build apps or functions, we just consume APIs,our focus is on what we are building.And because of that, we don’t notice or pay much attention to think about the design or structure of the api we use or appreciate it. so when someone asks “what makes a good API?” we blank.

but here’s the shift: think of an API as a software product.

when we hear “software product,” what pops in mind? specifications,backward compatibility, availability and things that relying on it, downtime is a nightmare, versioning and finally ability to evolve.

guess what? same rules apply to APIs.

so, a well-defined API has:

a clear specification
a solid contract and it sticks to it

and here’s the thing: with humans, contracts can be flexible. you order pasta, they mistakenly bring curry, you can call it out, they apologize, fix it.

but software? nah. it’s strict. code doesn’t “understand” misunderstandings. if your API promises pasta, it better deliver pasta.

that’s why a good API is all about:

contract discipline → never betray what you promised
availability → if your API is down half the time, who’ll use it?
evolution without breaking shit → business + tech are always moving. APIs need to evolve but still keep backward compatibility so current users don’t break.

of course, sometimes we can’t evolve without breaking old stuff. that’s where API versioning comes in. when you can’t maintain backward compatibility, you roll out v2 (whether via URL versioning or headers). the old consumers keep working, while new ones move forward.

so, a good API is a software product: reliable, backward-compatible when possible, and able to evolve without chaos.

API classifications (not what you think)

so far you’re clear on what an API is and what makes it good. now let’s zoom out to classification.

and no, i’m not talking about REST vs SOAP. those are styles. what i’m talking about is different dimensions of classification.

because APIs aren’t in one big hierarchy with one boss. instead, you can classify them by different aspects:

by audience → who uses it? public (anyone), private (internal only), or partner (shared with specific parties). the ones you usually meet are public APIs.
by access medium → what domain it lives in. web API, library API, OS API, hardware API.
by communication style → how the client talks and how data flows. could be REST (resources + HTTP verbs), GraphQL, or SOAP.
by package → how it’s delivered. raw endpoint? SDK (ready-made lib)?
by domain/use case → what problem it solves. cloud API, payment API, social API, etc.

Aight so now you know that infact an single api can be classified under different dimensions and still fall under multiple categories the same time.

sheesh!!that was a whole load of info right?

but now, if someone asks you what an API is, you won’t just parrot some textbook line. you’ve got a full picture, with intuition.

go through this a couple of times if you’re still not comfy.My goal isn’t to cram definitions in to your head instead it’s to have that natural, intuitive feel of “i know what an API really is.”

so until we meet again ✌️

What Happens When Code Runs Without an OS? Exploring CPU Execution, Memory, and Interrupts

Bhushitha Hashan — Sat, 14 Jun 2025 14:34:00 +0000

When writing code that runs without an operating system "bare-metal code", you're not dealing with the luxuries of system calls, drivers, or protected memory. You're dealing directly with the CPU and memory as they are. Understanding how the CPU actually behaves in this state,how it executes, loops, crashes, and responds to interrupts is foundational for developers and systems programmers.

Let’s break this down from the ground up.

Instruction Flow: The CPU Moves Forward By Default

At its simplest, the CPU is a machine that fetches instructions from memory and executes them, one after another. This sequential behavior is driven by a special register: the Program Counter (PC), or in x86, the Instruction Pointer (IP).

The Program Counter holds the address of the next instruction to execute. After executing an instruction, the CPU increases the PC to point to the following one. That’s how programs “move forward” .line by line, byte by byte.

Example in x86 assembly:

mov eax, 5
add eax, 2

After mov, the PC is incremented, and it proceeds to add. Unless told otherwise, the CPU just keeps marching forward.

Control Flow Is Yours: Loops, Jumps, Branches

But that "forward march" isn’t locked in. Assembly provides full control of program flow through jump instructions (jmp), function calls (call), loops (loop, jnz, etc.), and conditional branches.

For example, you can build a loop like this:

start:
  dec eax
  jnz start

This code counts down from whatever value is in eax, repeatedly jumping back to start until eax hits zero. You’ve created a backward loop, manually. The CPU isn't "thinking" in directions it's just following whatever address it's told to fetch next.

Memory Isn’t Sequential: You Can Reuse and Overwrite Freely

The CPU also doesn't treat memory like a one-way street. It's just a flat space of addresses and you can write, erase, and jump around in it freely. For instance:

mov [0x1000], eax    ; write eax to memory
mov eax, [0x1000]    ; read it back

That’s direct memory access. No protection, no guards unless you write them.

You could even store instructions themselves in RAM and jump between them as needed. This lets you build dynamic code flows, jump tables, or even self-modifying code (if you're careful and a little daring).

Manual Loops Across Memory Locations

You don’t even have to put your code in one spot. Here’s an example of a manual loop jumping between non-sequential locations:

; Assume:
; 0x0000: mov eax, 5
; 0x0003: jmp 0x0010
; ...
; 0x0010: add eax, 2
; 0x0013: jmp 0x0000

In this flow:

The CPU starts at 0x0000, sets eax to 5,
Jumps to 0x0010, adds 2 to eax,
Jumps back to 0x0000 — and loops.

This kind of manual control over memory and instruction flow is exactly how low-level systems work .The CPU is simply obeying pointers and doing what it’s told.

Crashes and CPU Chaos

If you mess up and overwrite your instructions, jump to invalid memory, or create an infinite loop there’s no safety net. No OS to save you. The CPU may freeze, reboot, or enter undefined behavior.

Here’s an infinite loop that’ll run forever:

start:
  jmp start

And a more useful loop:

mov al, 0
loop_start:
  inc al
  cmp al, 10
  jne loop_start
hlt

This code counts from 0 to 9 and then halts the CPU. That hlt instruction is essential otherwise the CPU would just keep reading random memory and likely crash.

The CPU Never Stops ,Unless You Tell It To!!

The CPU doesn’t know when to stop. It doesn’t assume your program ends after a few instructions. If you don’t explicitly stop it with hlt or reset it via hardware, it just keeps going. It’ll execute whatever’s next — even if that means garbage data in RAM.

This is why real-mode programs and BIOS routines are so strict about handling “what’s next.” In the absence of guardrails, everything is your responsibility.

Interrupts Still there Even Without an OS

Let’s take a deeper dive into interrupts. Yes, even with no OS at all, the hardware like a keyboard or timer can still fire interrupts.

For instance:

The keyboard fires IRQ1
The system timer fires IRQ0
These go to the Programmable Interrupt Controller (PIC)
The PIC forwards them to the CPU

The CPU, on receiving an interrupt, checks its Interrupt Vector Table (IVT) to find the address of the relevant handler.

But here's the catch: if you haven’t set that handler up, the CPU jumps into random memory. That’s an instant crash.

BIOS: The Unsung Hero of Early Execution

During early boot, you're not completely alone.if BIOS is still active, it provides basic interrupt services. You can use them like functions:

mov ah, 0
int 16h   ; BIOS keyboard input

These BIOS interrupts work only in real mode. As soon as you leave that mode or overwrite the handlers, you're on your own.

The Interrupt Vector Table (IVT): What It Is and Where It Lives

The IVT is a fixed table in low memory, from 0x0000 to 0x03FF. It holds 256 entries, each 4 bytes (2 bytes offset + 2 bytes segment), mapping interrupt numbers to handler addresses.

So:

INT 0x09 → CPU looks at 0x0024 to 0x0027
Reads the pointer there
Jumps to that address to run the keyboard handler

The BIOS sets this up on boot, giving you basic services. But if you're writing your own OS or bootloader, you'll need to set your own IVT and do it carefully.

RAM Is Empty at Power-On! So Where Does IVT Come From?

RAM is volatile,and it holds nothing on startup. So how does the IVT get there?

It’s written by the BIOS.

Here’s what happens at power-on:

Power is turned on
The CPU begins executing at address 0xFFFF0 — in ROM
BIOS code runs:

Initializes RAM, screen, keyboard
Writes the IVT into RAM
Loads a bootloader (e.g., GRUB or your own code)

This boot process is precise and hardware specific. Without BIOS or UEFI, you’d have to manually write this entire sequence, including the IVT.

Disabling Interrupts With `CLI`

Until your IVT is ready, interrupts are dangerous. A timer or keyboard interrupt might fire and jump to uninitialized memory.

To prevent this, use:

CLI   ; Clear Interrupt Flag

It tells the CPU: “Ignore all hardware interrupts for now.”

Later, once your handlers are in place, re-enable interrupts:

STI   ; Set Interrupt Flag

This flow is critical when setting up your own OS kernel or bootloader interrupts must be carefully managed from the start.

You Can’t Use All of RAM Freely in Real Mode

The IVT sits at 0x0000 – 0x03FF. That memory is off-limits unless you're replacing the table. Similarly, 0x0400 – 0x04FF is the BIOS Data Area also reserved. And 0xA0000 – 0xBFFFF is often used for video memory. Writing into these areas without knowing their purpose will break things fast.

Here's a rough map:

0x0000 – 0x03FF: IVT
0x0400 – 0x04FF: BIOS Data Area
0xA0000 – 0xBFFFF: Video memory
0xF0000 – 0xFFFFF: BIOS ROM mapping

Only areas outside these regions are safe, unless of cpurse you know exactly what you’re doing.

Final Thoughts: The CPU Is Obedient, Not Intelligent

The CPU has no opinion. It doesn’t know what a keyboard is, or what a loop is, or that you're trying to build an operating system. It obeys instructions, fetches bytes, and jumps wherever you tell it even into chaos.

This is your playground.

When you write bare-metal code, you’re writing the rules of the world. You’re building not just a program, but a miniature reality that the CPU inhabits it and it goes on until you tell it to stop.

And that, right there, is the power of low-level programming.

Wrapping Up

Diving into bare-metal programming feels like stepping into a new universe one where you control every bit and byte. This direct control is both thrilling and challenging because there’s no OS to hold your hand.

If you're passionate about systems programming or OS development, you're not alone. I’m learning from scattered books, online resources, and AI assists.piecing it all together step by step. If there are passionate experts out there who care to offer guidance, share insight, or steer me in the right direction, feel free to reach out.

And if you spot mistakes, oversights, or have corrections to offer, I genuinely welcome them . drop them in the comments. I’m here to learn, explore, and build this world from the ground up.

References: OSDev.org
: Programming from the Ground Up by Jonathan Bartlett

Why Everything Inside Your Computer Is Just Numbers

Bhushitha Hashan — Fri, 13 Jun 2025 10:22:48 +0000

When you power on your computer, it might seem like magic: a machine with flashy lights, crisp graphics, and powerful AI all running seamlessly. But underneath all of that, your computer is really just a highly sophisticated number-cruncher. It doesn’t "understand" in any human sense instead it processes raw numbers and bytes.

In this article, we’ll explore:

How the CPU wakes up and starts executing instructions
What instructions look like in memory
How the CPU knows where instructions start and end
The role of architecture in instruction size and format
The Von Neumann architecture’s influence on how programs and data coexist in memory

Understanding CPU Instructions in Memory

At its core, a CPU instruction like:

mov eax, 1

is just a sequence of bytes stored in memory. The CPU does not see "mov" or "eax" as words; it sees raw binary numbers.

In machine code, that instruction is represented as the following five bytes (in hexadecimal):

B8 01 00 00 00

Each byte occupies one memory address. So in memory, this sequence is laid out like this:

At some starting address (say, 0x00000000), the byte B8
At 0x00000001, the byte 01
At 0x00000002, 00
At 0x00000003, 00
At 0x00000004, 00

The first byte (B8) is the opcode, which tells the CPU: “Move an immediate 32-bit value into the EAX register.” The next four bytes (01 00 00 00) are the actual 32-bit little-endian value to move (in this case, the number 1).

Memory Is Just Bytes With Addresses

Think of memory as a huge row of lockers, each holding a single byte a number from 0 to 255. Every locker (byte) has an address, so the CPU knows where to find data or instructions.

For example:

Address 0x00000000 might hold 123
Address 0x00000001 might hold 065
Address 0x00000002 might hold 255

And so on.

All data, whether numbers, text, images, or instructions, is ultimately just bytes stored in these lockers. The meaning depends on how software interprets those bytes.

Storing Data and Instructions as Numbers in Memory

At the most basic level, a computer’s memory is a sequence of bytes ,small storage units that each hold a number between 0 and 255. Everything stored in a computer, whether text, numbers, images, or instructions, is ultimately just these numbers.

How Is Text Stored?

Text is stored using character encoding standards such as ASCII. For example, the string "HELLO" is stored as the sequence of bytes:

[72, 69, 76, 76, 79]

Each number corresponds to the ASCII code for a letter (72 for 'H', 69 for 'E', etc.).

How Are Numbers Stored?

Numbers can be stored in two primary ways:

As text: The characters '1', '0', '0' are stored as ASCII codes [49, 48, 48].
As raw numeric values: The integer 100 stored directly as the byte 100.

This distinction is important because the CPU only processes bytes. The meaning of those bytes depends entirely on context,whether they represent text, numbers, instructions, or other types of data.

If Everything Is Just Numbers, How Does the CPU Know What to Do?

This raises a fundamental question: if memory is just numbers, how does the CPU know which numbers are instructions to execute and which are data?

The answer lies in the way the CPU is designed and how software prepares the system.

CPU Instructions Are Numbers Too

Every instruction that a CPU executes such as MOV, ADD, or JMP is encoded as a binary number known as an opcode.well talk about opcodes in detail in a bit.

For example, on x86 processors:

Opcode (Hex)   Instruction
------------   -----------
B8             MOV EAX, immediate
05             ADD EAX, immediate
C3             RET (return)

The CPU contains a decoder that interprets these binary patterns as specific instructions.

How Does the CPU Identify Instructions?

Press the power button, and your CPU begins with no knowledge of its surroundings.
The CPU does not inherently distinguish instructions from data. Instead, it begins executing instructions from a specific memory address known as the instruction pointer.This address points to a special, read-only area called ROM (Read-Only Memory), where your BIOS or UEFI firmware lives. The CPU fetches its first instructions from this ROM chip.

At this address, the CPU reads bytes and interprets them as instructions in sequence. If the bytes at the instruction pointer correspond to valid opcodes, the CPU executes them accordingly.

It’s important to note that the RAM (random access memory) is uninitialized and doesn’t contain meaningful data at this early stage.

The operating system or bootloader sets the instruction pointer to the start of the program’s code segment, guiding the CPU to interpret that memory region as executable instructions.

What’s the Difference Between Code and Data?

At the hardware level, there is no intrinsic difference between code and data—both are just numbers stored in memory. The distinction arises from how the system uses those numbers:

If the CPU executes the bytes, they are treated as code.
If the program reads or writes the bytes, they are treated as data.

This concept is central to the Von Neumann architecture, where code and data share the same memory space but are used differently depending on context.

What Happens If Code and Data Get Confused?

If the CPU attempts to execute data as code, it will misinterpret the bytes, often causing crashes or unpredictable behavior. Modern operating systems implement memory protection mechanisms to reduce such risks by separating code and data into distinct regions of memory.

How CPU Architecture Influences Instruction Size and Format

Instruction size depends heavily on the CPU architecture. For example:

On modern x86 or x86_64 CPUs, instructions are variable length — they can range from 1 to 15 bytes.
The instruction mov eax, 1 takes 5 bytes because it includes an opcode byte plus four bytes for the 32-bit immediate value.
On simpler 8-bit CPUs like the 6502 or Z80, instructions are generally shorter (often 1 to 3 bytes).

What Is an Opcode?

An opcode (operation code) is a byte that encodes the CPU instruction type. It tells the CPU what to do next.

For example:

B8 means “move an immediate 32-bit value into EAX”
89 means “move a register into memory or another register”
C3 means “return from subroutine”
90 means “no operation” (NOP)

When the CPU reads an opcode, it knows exactly how many additional bytes to read for operands (like registers, immediate values, or memory addresses) based on the opcode’s meaning.

How Does the CPU Know Where Instructions End?

The CPU follows a strict fetch-decode-execute cycle:

It fetches one byte from the current instruction pointer.
It decodes that byte by looking it up in an internal opcode table.
The opcode tells the CPU whether more bytes need to be fetched and how many.
The CPU fetches the remaining bytes (operands).
It then executes the instruction.
The instruction pointer is updated to the next instruction’s first byte.
The cycle repeats.

Because of this design, instructions are self-describing in length. The first opcode byte inherently defines the size and format of the entire instruction.

For example, the instruction mov [eax + 4], ebx translates to the bytes:

89 58 04

Here:

89 is the opcode for a register/memory move
58 is a ModR/M byte that specifies the memory location (eax plus an 8-bit displacement)
04 is the displacement value

A Quick Overview of Instruction Components

Many x86 instructions are composed of multiple parts:

Optional prefix bytes for repeat or segment overrides
The opcode itself (the main instruction code)
Optional ModR/M byte specifying addressing modes and registers
Optional SIB (scale-index-base) byte for complex memory addressing
Optional displacement bytes for memory offsets
Optional immediate bytes for literal values

The CPU’s decoder logic knows how to parse these parts step-by-step as it reads the instruction stream.

Von Neumann Architecture and Shared Memory

All of this ties back to the Von Neumann architecture concept: program instructions and data share the same memory.

This means that instructions like mov eax, 1 are stored as numbers, just like data values.

The CPU doesn’t inherently distinguish code from data — it relies on the instruction pointer to fetch bytes in sequence and interpret them as instructions.

This architecture offers flexibility but can also introduce vulnerabilities, such as when data is mistakenly executed as code.

Wrapping Up what we discussed so far

The CPU begins execution from a fixed ROM address containing firmware.
Memory is a continuous sequence of bytes, each with a unique address.
Instructions are sequences of bytes, starting with an opcode byte that tells the CPU how to decode the rest.
Instruction size varies based on architecture and specific instruction.
The CPU uses internal decoding logic and lookup tables to fetch and execute instructions correctly.
The Von Neumann architecture explains why instructions and data coexist in the same memory space.

This article is designed to give you some understanding of what’s happening inside your CPU when it starts running code beneath the surface of all the software and graphics you see.

Thanks for reading!

References:Programming from the Ground Up by Jonathan Bartlett

Beyond Blueprints: Seeing the Soul of Java's Classes and Objects

Bhushitha Hashan — Tue, 08 Apr 2025 09:42:45 +0000

We've all heard the simplistic analogy: "A class is a blueprint, and an object is a house." While it offers a rudimentary starting point, it barely scratches the surface of the profound relationship between classes and objects in object-oriented programming, especially within the robust ecosystem of Java. Let's discard the oversimplifications and embark on a technical and philosophical exploration to truly grasp their significance in crafting resilient and elegant software.

1. The Technical Foundation: A Java Perspective

Within the context of Java, classes and objects have particular meaning.They are not mere abstract concepts,they are fundamental building blocks with distinct roles at different stages of their lifecycle.

Class: The template of Behavior and Structure

A class in Java is a compile-time construct, a meticulous definition etched in your source code. It acts as a comprehensive template, dictating the very essence of the entities your program will manipulate. This template encompasses,

State (variables):: These are the variables declared within a class (e.g., int age, String name). They represent the data that an object of this class will hold, defining its characteristics. Think of them as the attributes that describe an entity.instance variables define the precise memory footprint of each object. When a class is loaded, the JVM calculates field offsets based on type signatures in the class file - primitive types like int (4 bytes) and long (8 bytes) get fixed-width slots, while object references consume either 4 or 8 bytes depending on JVM configuration.Each object header (typically 12 bytes) contains a pointer to this layout metadata in the class's klass structure.Static fields are treated differently,they stored in the class's mirror object in Metaspace, not within individual instances.
Behavior (Methods):: These are the functions defined within a class (e.g., calculateSalary(), login()). They encapsulate the actions that an object of this class can perform, defining its capabilities and interactions in controlled manner.When a Java class is loaded, the JVM stores its bytecode and metadata, including the structure of fields and methods, within the Method Area. For classes with overridable instance methods, the JVM creates a vtable in the Method Area, which is an ordered array of pointers to the actual method implementations (either bytecode in the Method Area or compiled native code in the Code Cache). Similarly, classes implementing interfaces may have itables in the Method Area to facilitate interface method dispatch. Each object created on the heap contains a pointer to its class's metadata in the Method Area, allowing the JVM to access the appropriate vtable or itables. During method invocation on an object, the JVM uses the object's class pointer to locate the vtable or itable and then uses a precomputed index to find the memory address of the method's executable code, enabling dynamic dispatch and polymorphism. Static methods and constructors, not subject to dynamic dispatch, are also stored in the Method Area and are invoked directly using the class metadata. Instance fields reside within the object on the heap, while static fields are stored in the class's metadata in the Method Area.
Identity (Constructors): These special methods dictate how a new object of the class is initialized. They set the initial state of an object when it is created, giving it its initial identity.At a raw, low-level, when new is executed, the JVM first allocates a contiguous block of raw bytes in the heap, the size determined by the class's field layout. This memory is initialized to zero. Then, the appropriate constructor's bytecode is executed. This bytecode directly manipulates the memory at specific byte offsets corresponding to the instance fields, writing the initial values provided in the constructor call or default values. The constructor might also call other methods, including the constructor of the superclass, which similarly manipulates the raw byte representation of the object's inherited fields. Finally, the new operation returns the memory address of this now-initialized block of bytes as a reference to the newly created object.
Relationships (Inheritance, Interfaces): Java's extends and implements keywords within a class definition establish how this class relates to other classes and interfaces, enabling code reuse and polymorphism.At the JVM level, inheritance via extends creates a hierarchical vtable structure where method calls are resolved through virtual method table lookups - each class maintains a table of method slots, with subclasses copying and overriding parent entries, while invokevirtual opcodes use this table for dynamic dispatch. Interface implementation (implements) generates separate itables (interface method tables) that map interface methods to concrete implementations, resolved through invokeinterface which performs additional overhead for interface method resolution including checking all implemented interfaces.

Finally A class exists solely in your source code. It is the input for the Java compiler, which then translates this human readable definition into bytecode the language understood by the Java Virtual Machine (JVM).the moment your program runs and touches that class, the JVM brings it to life in memory. It builds this whole shadow version of your class in Metaspace.Method tables, reflection junk,Constant Pool Resolution,Class Hierarchy Info ,JIT Optimization Hooks which the Just-In-Time compiler uses to aggressively optimize hot code paths etc are few.

Object: The Living Instance

An object, on the other hand, is a runtime instance of a class. It is the tangible manifestation of the blueprint defined by the class. When your Java program runs, objects come to life, occupying precious memory within the heap.
When a new object comes into being within the JVM's heap, it carves out a specific chunk of raw bytes from the available memory. The size of this chunk isn't a simple tally of its declared fields; it also includes a bit of extra baggage known as the object header. This header is like an internal ID tag, holding crucial low-level information. One part, the "mark word," carries bits that track things like the object's unique hash code, its status for garbage collection, and any active locking information. Another vital part is the "klass pointer," which is essentially a direct memory address acting like a signpost, pointing the JVM back to the detailed blueprint of the object's class stored in the Metaspace.

Right after this header, the actual data fields of the object reside. For basic data types like integers and long numbers, their raw binary values are laid out directly in the allocated memory, starting at specific positions (offsets). The JVM decides these positions based on a careful arrangement process that considers the order in which the fields are declared and also any alignment rules that the computer's processor might require for optimal performance.

When you tell an object to do something (invoke a method), the special this keyword you often see is, at its heart, just the raw memory address where that object lives in the heap. The JVM takes this address, along with the name of the method you called, and uses the "klass pointer" from the object's header to find the class's instructions. Within these instructions, it locates the vtable (for regular methods) or itable (for interface methods). These tables are like internal address books, containing the raw memory locations of the actual machine code that makes the method run. Finally, the object's unique "identity" at the most fundamental level is deeply connected to its unique starting address within the vast landscape of the heap, and the hashCode() method often cleverly uses this address or some derived value to give you a more human-friendly integer representation of that uniqueness.

2. The Philosophical and Design Significance: Beyond the Code

Stepping aside the technical specifications,Now let's delve into the philosophical and design implications of classes and objects, understanding their true meaning in crafting robust and maintainable software.

Class as a "Rulebook": The Abstract Definition of an Idea

Think of a Java class as a strict and detailed rulebook. It lays out exactly what kind of data its objects will hold.like numbers, strings, or lists — and what actions they’ll be able to perform,like depositing money or printing details. This isn’t a gentle suggestion; it’s a contract. Every object created from that class must follow these rules without exception. The Java Virtual Machine (JVM) enforces this behind the scenes, ensuring that your objects behave predictably and consistently.

Let’s take a real-world example: a BankAccount class.

This class doesn’t just suggest that a bank account should have a balance and an accountNumber. It defines them as essential parts of what makes a bank account a bank account. It also outlines specific operations, like deposit(), withdraw(), and getBalance(). These aren't optional features — they are the core capabilities every BankAccount object must have.

But there’s more. A good class often comes with invariants — unbreakable rules that must always hold true. For instance, a BankAccount might require that the balance can never drop below zero, and a withdrawal can only happen if there’s enough money in the account. These built-in checks act like safety rails, preventing your objects from getting into illogical or invalid states.

Object as a "Tangible Entity": The Concrete Realization

Now here’s where it gets more interesting.

If a class is the rulebook, then an object is a living, breathing copy created by following those rules. When your program runs and creates a new BankAccount, that’s no longer an idea — it’s a real instance in memory, with its own data and its own life. It might have a balance of $500 and an account number like 12345. You can interact with it: deposit money, withdraw cash, or check its balance.

And here’s the cool part,if you also have a bank account in the program, it’s built from the same blueprint but lives a completely separate life. Your account might have $2,000, and mine $500. Even though both are BankAccount objects, each one has its own memory, its own values, and its own identity.

Just like two houses built from the same blueprint can have different paint colors and furniture, two objects of the same class can have different data, but still obey the same structural rules. That’s the power of object-oriented programming.

Finally,A well-designed class becomes a promise. It says, “Every object built from me will behave in a certain way and hold certain data and no surprises.” That kind of consistency is what allows large, complex programs to stay manageable.

So the next time you define a class, remember, you're not just typing out some syntax. You're crafting a set of rules that will shape real, living things in your program's world.Each one with its own identity, yet all bound by the same laws you set.

And when you create an object, you’re not just allocating memory,you're giving life to an idea.

Forem: Bhushitha Hashan

Stop Wondering How Virtual Memory Works!!!

The Scene: Late Night at the SRE Lab

Speed vs Truth: Understanding Redis the Way Engineers Actually Do

Late Afternoon, Real System, Real Confusion

What Redis Actually Is (Explained Like You Mean It)

The First Mental Breakthrough

Why We Even Need Redis

Where Things Start Getting Dangerous

The Fear Kicks In

The Second Mental Shift: Not All Data Is Equal

Left Side

Right Side

Two Ways to Write Data

1. Write-Through

2. Write-Behind

The Trade-Off Nobody Escapes

The Data Loss Gap (This One Matters)

So We Add a Queue

When Things Go Wrong (And They Will)

The Subtle Problem With “Safe Enough”

Three Things Real Systems Add

1. Idempotent Writes

2. Assume the Queue Lies

3. Retry Properly

The Final Realization

Updating the Mental Model

But There’s Still a Subtle Problem

Read Repair (The Quiet Fix)

Everything Comes Together

The Final Understanding

The One Sentence That Matters

If You Walk Away Remembering This

A Deep Dive into Kernel Context Switching

Why the GS Register is the Kernel’s North Star

The Transition: From User to Kernel

Entry and the Trap Frame

The RSP Dillema

The Great Teleportation: Updating the Identity

The Performance Shortcut: Beating the Memory Latency

The Great Teleportation: How Context Switching Actually Works

1. Freezing Task A

2. The RSP Swap

The Layered Timeline: Why the Stack is a Time Machine

The Two Layers:

The Final Piece: The Kernel RIP

The Blueprint: struct pcpu_hot

SLIs, SLOs, SLAs: The Guide to SRE’s Secret Sauce

SLIs : Service Level Indicators: The User’s Reality Check

SLOs: The Chill Target You Actually Give a Damn About

SLAs: The Contract With Your Customers (aka The Lawyers Show Up)

Error Budget: How Much Failure is Allowed

Analogy: Think Like the User, Not the Server

Why You Give a Damn as an SRE

Linux Privileges:Peeling Back the Curtain Of How Linux Really Handles Users, Privileges, and Processes

Introduction

UIDs: The Kernel Doesn’t Give a Damn About Names

Setuid: Privilege Already Baked Before You Touch Anything

Dropping and Regaining Privileges Safely

When Setuid Is Not Set

Rules of Privilege Escalation

Login Shells and TTYs: The “Fall From Grace”

sudo, su, and Variants

Process Startup: Everything Happens in Order

Mental Model

Why This Matters

Wild Ride from Raw Syscalls to Figuring Out NSS and libc

That WTF Moment: /etc/nsswitch.conf

Okay, Now NSS Makes Sense

How It Actually Works

The Secret Sauce: libc Beyond Raw Syscalls

NSS Modules Still Use Syscalls Under the Hood

How This Hit Me

Layers of the System (Mental Picture)

My Reflection

The One-Liner to Finalize It

API Demystified: From Confusion to Confidence

what even is an API?

ok, cool now, but what makes an API “good”?

API classifications (not what you think)

The Blueprint: `struct pcpu_hot`

`sudo`, `su`, and Variants

That WTF Moment: `/etc/nsswitch.conf`

Disabling Interrupts With `CLI`