← HOME
Part 1

What an Operating System or Kernel Really Is?

📅 November 10, 2025 ⏱️ 15 min read 🏷️ Basics
Hey fella, from today we will be writing our own OS, this series unlike others is frank and covers a lot of stuff from 0, it doesn’t care about academics yet deep dives into most stuff, my job is to make you a master with the perfect combination of layman’s language and technical stuff.

Prerequisites: C basics, what are variables, bits and bytes, what is memory, what are compilers, what are data types, etc. CPUs have registers. You must know what those are, what are memory addresses on ram, pretty much if you have learnt C basics and have some light surface level knowledge about cpu and ram you are good to go.

Operating system architecture showing layers from hardware to applications
Figure 1.1: Hehehe what to say, I made this in Canva.

What an Operating System Really Is?

Now one can say an operating system is the fundamental software layer that sits between computer hardware and application programs. It manages system resources... meh thats too abstract and stupidly overwhelming we dont like abstract, lets minimise it to the core.

An OS/Kernel really is just code, 0s and 1s, meant to be executed by the CPU. Well yeah thats all it boils down to, lets strip it event more, lets make it naked. A kernel/OS (code) essentially just does 3 things when it comes to doing things.

1. Read/Write from/to CPU registers.

2. Read/Write from/to dram

3. Read/Write from/to mmio device registers

And these 3 things are just memory hardware meant to hold data and nothing else, dont worry I will be explaining them

Well that's it, that's all we are going to code, these 3 tasks, all other code will be just about preparing data to write and interpreting data that was read. It is no rocket science, at core tbh writing OS is just data managment in an optimized way. Memory managment, process scheduling, and every other core kernel functions lie within umbrella of these 3 kinds of read and writes.

But hey Naitik what? How do things happen then?

If all we are doing is writing and reading data from these 3 memory places, then how does stuff happen? How tf does my screen changes pixel colors and how my speaker plays music, And HOW my OS performs actions as per my mouse and keyboard inputs?

See as I said kernel is just code, it is held on ram, yes the physical 4gb,8gb,32gb ram stick (its called dram). And CPU reads ram and executes this code as the system starts or one can say boots. How it got there initially will be answered in next parts. All the kernel code is about reading and writing bits to memory, different kinds of memory.

Different kinds of memory is the subtle detail here, we discussed them above, all 3, lets talk about the first one now that will clear it all.

MMIO (Memory-Mapped I/O)

As you know that data in memory can be located with something called address, looks like 0xFEDC0000. In your normal coding journey you must just have used dram to read/write data, thats where variables are stored. But there is another kind of memory its called mmio space.

Now if kernel has a line of code that says:

*(volatile uint16_t*)0xB8000 = 'A'

We are technically just writing to change data at 0xB8000 address to 01000001, thats binary for A. But believe it or not it will actually add A to your screen. Also this code is for representation only, its dummy, dummy.

See what happens is, as your cpu reads this line of code, there is something called memory controller which knows if address belongs to mmio space or normal dram. It detects hey its not a normal address, its for some hardware, its for the VGA!

Yes your system has different addresses reserved for different hardware! Now the memory controller routes it to memory bus which is like a metro fricking system on the motherboard. It takes it to the vga registers and drops it there. Later VGA does what we asked it to do, display the A.

Each hardware device has its own registers which it uses to receive input data from cpu and provide outputs.

Overall MMIO is the way your kernel talks to the hardware devices, there is no direct shit like hey networkcard.status=ON We just write to memory addresses of mmio space, to make stuff happen.

For adding to a cpu register, things are different, since cpu directly has access to these, if it reads a kernel code having instruction for manipulating, it exclaims “Ah its for me!”, then it just directly manipulates the register, no mmio, bus involved.

But what about Input data?

That was about making an output, changing things and doing an action, what about reading inputs? Maybe the vga sent an error back, the user pressed a key on the keyboard, the network card is sending packets it received from the external world.

For inputs an interesting process happens, let’s talk about the keyboard. The CPU first receives if any key is pressed we call this i/o. When the cpu receives it what it does is it goes to part of kernel (a function) which handles inputs, we call it handler, and it generally obviously takes the input data as argument, so cpu interrupts everything else and run this handler code block, later it depends on us how we write our handler and how we use the received key data.

Wait, but how does CPU know which function to run when?

There is something called IDT (Interrupt Descriptor Table), as the name suggests it contains data for CPU, of which function to run on which devices interrupt, since kernel as code lies on ram, functions also lie on ram and have their own pointers. The IDT contains pointer to the functions. Actually we create IDT ourselves in later stages of booting when we are ready to handle inputs, IDT lies on dram as we store it and let CPU know its location by writing to a special register IDTR, with memory address or a pointer to the IDT table.

There is something called an interrupt controller, it gets the interrupts and knows which interrupt came from which device, and lets CPU know with an interrupt vector number, since that’s what the CPU uses to index into the IDT. So it can fetch the required handler function pointer address.

This is what happens for everything: a network card packet, interrupt! A file on usb pendrive interrupt and let the kernel know. And CPU mind you is very fast, it handles all interrupts from every fucking device so fast you dont even feel a delay when you press key and its typed while simultaneously the network card was sending packets for a youtube video playing in background.

Input Interrupt Flow
Figure 1.2: Input Interrupt Flow (Dont take the represented IDT litreally).

DMA or Direct Memory Access: Now one hardware can interrupt CPU and say that I have brought some data back, but giving entire data to CPU or asking CPU to read it from its register, which on itself cant hold a good amount, and then ask CPU write it to ram, as you may infer that would flood CPU with so much DATA and overhead! Instead hardware devices are given direct access to memory addresses on dram where they can directly leave data and just make an interrupt, cpu checks the output register of device through mmio, and gets pointer to the dram address where returned data was written, then run the kernel handler with the data.

Basically CPU isn’t flooded with copying large buffers — DMA lets devices place data directly into RAM and simply notify the CPU once done.

Confused Aren't ya?

Ok I think we have left him naked enough, lets just let kernel put the undergarments back

This whole proccess may seem overwhelming let me simplify, see Kernel once booting code ends isn't a series of code like level1 --> level2 --> level3 BUT its just a bunch of functions packed together to do stuff, these can be called in any order. See CPU is let known what these function do through IDT as I said, and you will see how kernel is all just about:

1. Scheduling Processes: that's about executing user ran applications, maybe ms word, chrome anything. Scheduler functions are all about giving to CPU what user wants to execute and deciding order and data flow.

2. Input Handling: that's about handling data returned from everything as user process ran, that data that vga has displayed chrome on screen and the data that network packet has got back with your google acc details it doesn't happen in a flow but a bunch of functions running and recieving data. Our job will be to bridge this received data so his acc data is also displayed as soon as chrome covers the screen.

The Rings

I use kernel and OS interchangabely but they do carry different meaning, OS is a broader term and kernel is a part of it and is the base layer of any OS, operating at ring 0 with full access. Layers in OS are just classification based on access, and Kernel is the base layer.

Ring 0  → Highest privilege (kernel)
Ring 1  → Medium privilege
Ring 2  → Low privilege
Ring 3  → Lowest privilege (user apps)

The CPU checks privilege in two ways:

For instructions: The CPU checks your current Ring level (from the CS register) before running privileged instructions. CPU is hardcoded to know which instruction is privelleged and which is not.

For memory access: There is Page tables, which act like a big lookup table. Each memory page has a User/Supervisor bit. If you're in Ring 3 and try to access a supervisor-only page, you get a Page Fault: "Ah you are not allowed!"

Registers

The last memory we discussed, so your CPU has registers, these are very tiny yet really fast memory, CPU has direct access to these, there are various kinds as you must know.

1.General-purpose registers: hold data or addresses temporarily, basically we can hold our normal data here during operations, like variables or pointers to them.

2.Program counter (PC): holds address of next instruction. Well since genrally upcoming instruction is already cached in L1, L2 or L3, CPU doesnt go to ram for every next instruction or line of code.

3.Segment Registers: CS (Code Segment) Register holds GDT and privelege level. Privelege level is the ring level 0,1,2,3 we talked earlier, determines if some instructions can be executed or not, so CPU checks level in CS registers last 2 bits, before executing the instruction.

There are many such registers we wont go through all of them in this chapter but for now understand register are used for both fast memory and some important variables such as ring mode we discussed.

"All a Kernel or essentially the entire OS is, is code and this code contains instructions to read and write to memory and nothing else, linux, windows, mac os, you name it, what it writes and read from the memory is the magic and how its executed by the cpu is the awe."

What's Next?

In Part 2, I will answer some important stuff about how C and assembly will be used during development of Our OS. How C and assembly will be combinedly used, and insights over special kind of C we will be using.

If you liked this you can help by, Buying me a Coffee. If you are broke unlike me, consider emailing to naitikmundra2008@gmail.com with your feedback and suggestions, highly appreciated.