DEV Community: Shreyash

Introduction to Linux Kernel

Shreyash — Thu, 23 Apr 2026 07:37:44 +0000

Context

I always wanted to understand what really happens between the hardware and the software we use every day. We often talk about Linux as an operating system, but the real brain behind it is the Kernel.

Let me tell you — the Linux kernel is one of the most important pieces of software ever built. It is the core layer that manages hardware, memory, processes, and communication between different parts of the system. Without it, your applications would have no way to talk to the machine.

What is the Linux Kernel?

The Linux kernel is the central part of the Linux operating system. It sits between user applications and the hardware.

In simple words:

Applications ask for services
The kernel handles the request
Hardware performs the action

This makes the kernel a kind of bridge, or control layer, between software and physical devices.

Why the Kernel Matters

We often take computing for granted. We open a browser, play music, connect to Wi-Fi, or read a file, and everything just works. But behind all of that, the kernel is doing silent work every second.

It manages:

Processes — deciding what runs and when
Memory — allocating RAM safely
Devices — controlling drivers for keyboard, disk, network, and more
File systems — handling data storage and access
Security — making sure programs cannot freely access everything

That is why the kernel is not just important; it is essential.

Kernel and Its Similarity to Firmware

A kernel is often similar to firmware in one important way: both sit close to the hardware and act as a control layer.

Firmware usually runs very close to the device and directly manages hardware behavior. The kernel does something similar, but on a larger and more flexible scale.

Both are responsible for:

Hardware interaction
Low-level control
System initialization
Stable communication with peripherals

The difference is that firmware is usually tied to a specific device or controller, while the Linux kernel supports a much broader and more complex computing environment.

What Makes the Linux Kernel Special?

The Linux kernel is special because it is:

Open source
Highly scalable
Widely used
Modular
Adaptable to many devices

It runs on everything from tiny embedded boards to servers and supercomputers. That flexibility is one reason it became so powerful in the first place.

Final Thoughts

The Linux kernel is the heart of the system. It is invisible most of the time, but it is always there, quietly making everything work.

I often think of it as the layer that gives structure to chaos. It connects hardware and software in a clean, controlled way. And that is exactly why learning about it is so valuable.

Introduction to Embedded Linux

Shreyash — Tue, 07 Apr 2026 11:56:34 +0000

Context

Most developers are familiar with software that runs on laptops, servers, browsers, or mobile phones. But there is another world where software does not run in isolation. It runs on devices that interact with the physical world — routers, gateways, industrial controllers, cameras, infotainment systems, and many other smart devices.

That world is where embedded Linux comes in.

At first glance, it may look like “just Linux,” but embedded Linux is really about using the Linux ecosystem to run software on resource-constrained devices that have a specific purpose. It sits between pure firmware and general-purpose computing, which makes it one of the most interesting areas in embedded development.

This article is a simple introduction to what embedded Linux is, why it is used, and what a beginner should understand before diving deeper.

What is Embedded Linux?

Embedded Linux is a Linux-based operating system designed to run on embedded hardware.

Unlike desktop Linux, which is made for general-purpose computers, embedded Linux is usually customized for a specific device. That means it may include only the components needed for that product and nothing extra.

In simple terms:

The hardware is built for a specific job
The Linux system is trimmed and configured for that job
The application runs on top of it and controls the device

This makes embedded Linux very powerful for devices that need:

Networking
Multitasking
File systems
Driver support

How Embedded Linux Differs from Firmware

This is one of the most important things to understand.

In firmware development, you often work very close to the microcontroller. You control peripherals directly, and the software usually runs as one main program.
In embedded Linux, the system is layered.

A typical stack looks like this:

Bootloader: Starts the hardware and loads the kernel
Linux kernel: Manages hardware, memory, processes, and drivers
Root filesystem: Contains system libraries and user programs
User-space programs: Actual software logic of the product

This layered structure makes embedded Linux more complex than bare-metal firmware, but also much more capable.

Cross-Compilation: A Key Concept

One of the first surprises for developers entering embedded Linux is that you usually do not compile directly on the target board.

Instead, you often use cross-compilation.

That means:

Your development machine builds the software
The output binary is meant for a different CPU architecture
The target board runs the compiled result

This is common because embedded boards may use ARM, MIPS, RISC-V, or other architectures.

Cross-compilation is one of the first practical hurdles, but once you understand it, the workflow becomes much smoother.

Final Thoughts

Embedded Linux is not just “Linux on a small board.” It is a complete ecosystem for building real products that need hardware control, networking, and application logic in one system.

The learning curve can feel steep at first because it combines so many topics at once. But once the pieces start making sense — bootloader, kernel, device tree, root filesystem, and user-space applications — the entire system becomes much easier to understand.

If you are coming from firmware or full-stack development, embedded Linux is a great next step because it teaches you how operating systems and hardware work together in real products.

It is one of the best places to learn how software meets hardware in the real world.

Switching from Full-Stack Development to Embedded Firmware.

Shreyash — Thu, 12 Mar 2026 11:41:26 +0000

Context

Most developers start their careers building software that runs on servers, browsers, or mobile devices. I started there too. My early work involved typical full-stack development — APIs, databases, backend services, and frontend applications.

But over time I became curious about something deeper :
The layer between a software and hardware, something that binds software to hardware for devices used in real time systems.

Almost two years later, I now work primarily on embedded firmware. This transition completely changed how I think about software engineering, debugging, and system design.

This article is not about one specific project. Instead, it's about the mindset shift required when moving from web software to firmware development.

Why I Moved from Full-Stack to Firmware ?

Full-stack development is powerful. You can ship features quickly, deploy globally, and iterate rapidly.

But embedded systems offer a different kind of challenge:

You interact directly with hardware peripherals
Debugging often happens without logs or stack traces.
Every byte and millisecond matters.
Problems often span hardware + firmware + communication protocols. That complexity is what pulled me in.

Working closer to hardware forces you to understand systems from the ground up.

Learning to Read Datasheets Efficiently

One of the most important firmware skills is extracting the right information from a datasheet quickly.
Datasheets can be hundreds of pages long. Reading them linearly rarely works.

Find the system overview first and understand the architecture:

communication interface (UART, I2C, SPI, CAN)
data format
initialization sequence

Identify the register map or command structure

registers
binary commands
structured packets

Once you understand the structure, the rest becomes easier.

Debugging in Firmware for a sensor feels Different

Firmware debugging often looks like this:

Send a command to a device
Capture the raw response
Decode the bytes manually
Verify checksum
Compare with documentation
Repeat until behavior matches expectations

Sometimes the problem isn't even in your code. It maybe a sensor issue, hardware issue, connector wires issue and anything related to hardware and that's why the debugging process sometimes feel tiring.

If you're a software developer curious about embedded systems, I highly recommend exploring this space. The learning curve is steep, but the insights you gain are incredibly valuable.