← 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.

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.

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, tbh consider kernel as an entire OS for now we dont need to go in detail, this is too much unnecessary theory tbh, you can google it.

"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, CPU registers will be discussed, 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.