Introduction: A Problem Hiding in Plain Sight

Direct I/O (O_DIRECT) has been a contentious feature in Linux since its introduction. Linus Torvalds famously called it a design “by a deranged monkey on some serious mind-controlling substances” back in 2002. Yet for years, it continued to work—mostly. Applications used it, databases relied on it, and virtual machines benefited from its zero-copy performance.

But something fundamental has changed. As modern software has embraced multi-threading at every level—from applications to filesystems within the kernel itself—a problem that was once manageable has become critical. The truth is stark: with O_DIRECT, there is no way to guarantee that nobody will touch your I/O buffers during the operation.

Introduction

I’ve been working on a new project that required high-performance UDP load balancing with dynamic weight adjustment. Traditional userspace load balancers introduce latency that’s unacceptable for our use case, so I decided to implement a kernel-level solution using eBPF (extended Berkeley Packet Filter).

The result is ebpflb_udp_wrr, an eBPF-based UDP load balancer that distributes incoming UDP traffic to local listeners using a weighted round-robin algorithm.

Why eBPF and XDP?

eBPF has revolutionized how we can extend kernel functionality without writing kernel modules or modifying the kernel source. Combined with XDP (eXpress Data Path), we can process packets at the earliest possible point in the networking stack—right when they arrive at the network interface—minimizing latency.

Introduction: The Illusion of Sequential Execution

When you write code, you naturally think in terms of sequential execution: instruction A happens, then instruction B, then instruction C. This mental model works perfectly—until you start writing concurrent code or working with hardware. Then you discover that modern CPUs, compilers, and memory systems conspire to execute your code in ways you never imagined.

The truth is that sequential consistency is largely an illusion maintained by your compiler and CPU to make programming tractable. But when multiple cores or threads are involved, that illusion breaks down in spectacular and subtle ways.

A Networking Mystery

Over the past two days, I found myself conducting a complete forensic analysis of my network. Something unexpected had changed the IP address of my main host’s bridge0 interface. Given that a critical React Server Components vulnerability had been released (GHSA-fv66-9v8q-g76r), and I had recently deployed several new Docker containers—some with access to the host Docker socket (I know, not ideal)—I immediately suspected a compromise.

The situation felt serious. By sheer luck, changing the bridge interface address cut all network access to my homelab, which at least contained the potential damage. I examined every Docker image on the system, but found nothing suspicious.

The Hardware Testing Challenge

When developing hardware, the challenging phase begins after the prototype is designed and PCBs are manufactured. The easy part—conceptualization and board design—is behind you. What follows is infinitely harder:

• Making boards electrically alive and verifying proper operation with electrical jigs and test equipment
• Programming and validating firmware behavior
• Testing the complete system’s functionality under real-world conditions
• Building the infrastructure—both hardware and software—to support comprehensive testing

For devices communicating via NMEA protocols, this challenge is compounded by the complexity of marine electronics standards and the difficulty of simulating real maritime data streams.

Why ESP32C5?

I’m researching hardware options for an upcoming project, and the ESP32 family appears to be the best fit for our current requirements.

For years, a major drawback of Espressif chips was limited support to 2.4GHz WiFi only. Why does this matter? Having a 2.4GHz device on a WiFi network degrades performance for all other devices, forcing users to set up separate WiFi routers just for 2.4GHz devices. Additionally, the initial configuration proved frustrating—when your phone is on 5GHz, the ESP Touch protocol doesn’t work reliably.

Using Compiler and ELF to Avoid Ifdef and Flags Hell for Selecting Runtime Features

I was digging into redis source recently and i came to realise some lesser know features
of gcc/clang needs some more publicity, so i will write about them here.

The problem: You want to get best of the CPU/Hardware/Features but usual way to do this
is either build for specific hardware or use runtime checks both have drawbacks.
First on a new hardware you need a new build and results in

Vevor 7 in 1 Wifi to Windy and HomeAssistant

For a long time i wanted to install a weather station but since
i have to put it on a roof which is easily accessded by outside
people i needed something on the budget side.

So during a recent Ali promotion i got one - Vevor 7 In 1 WiFi
model.

You need the WiFi version, there non-WiFi version which you can work
with too but you need to have RTL SDR dongles and recode radio data send
from the outdoor unit to the sensor. This post is about the WiFi only.

SDCC

Install from distribution repositories but you need at least version 3.7.0.

Source code is available at  http://sdcc.sourceforge.net/ .

When building you may want to disable some of the supported MCUs.

 

stm8-bin utils – get from https://stm8-binutils-gdb.sourceforge.io/

SPL Patches – get from https://github.com/gicking/STM8-SPL_SDCC_patch

Get the SPL for your device from st.com:

– STM8S/A: “STSW-STM8069”
– STM8L10x: “STSW-STM8012”
– STM8L15x-16x-05x-AL31-L: “STSW-STM8016”
– STM8TL5x: “STSW-STM8030”

How to update makefiles - use examples as base

 

How to debug : need a jtag connection or a serial output for hardcore printf debugging

 

Catching up with the latest ESP8266_NONOS_SDK_V2.0.0_16_07_19

– got into some issues.

Seems like Espressif integrated some time compatibility functions into libmain.a which i already had into the tree, most likely due mbed tls port

If you have millis(), micros(), mktime() and friends then you may need to comment them out.

There is one exception – open soruce xtensa gcc provides time() which is required by ANSI C so it is in  – platform must provide gettimeofday.
The problem is time() is in libmain from the SDK – so the workaround is to strip time from your libc and use the one in the SDK.