这座港口从不打烊。潮水不等人，货轮也不等人，港务长立下一条铁律：任何理由都不能让港口停摆——闸门不能拆，航道不能封，值班室的钟一秒都不许停。

可港务长又总有临时的念头：数一数今天挂着某国旗的船有多少艘，或者某类货物一经过就记一笔。麻烦在于，全港口每一道闸门的规矩，都由地窖深处那台总控齿轮机统一驱动——想给某个闸口加双眼睛，就得先停下整台齿轮机，拆开重新咬合齿轮，再重新启动。可齿轮机一停，全港口所有闸门都跟着停摆，这正是港务长绝不答应的。

于是港口添了个哨站文员的差事。谁想在闸口”顺便看一眼”，先得写一张便条，交给一位出了名苛刻的老稽查员过目。这位稽查员从不放行含糊的便条：不准写”绕圈子等着”这种话——不许死循环；必须在读完一遍货单之前写完——步数有上限；也不准伸手去翻不属于自己的抽屉——不许越界读写。只有条理分明、保证读完就收笔的便条，才会被盖章批准，钉在闸口的哨墙上。

便条一钉上去，稽查员就不必再守着了。它会随着每一艘船经过闸口，被自动念一遍，快得像是刻进了闸门的齿轮，而不是每次都要摸出来重新辨认笔迹。念便条的人不记院子里所有的事，只在墙角那本公用记事本上添一笔它被交代要记的——”今天第37艘红旗船”。这本记事本随时供港务长翻阅，却轮不到哨站文员私自撕页或改字。

最妙的是，哪天港务长想撤掉这张便条、换一张新的，只消把旧的摘下来，钉上新的。闸门、航道、整座港口的骨架，没有一根钉子需要挪动。

——到这儿，你大概已经认出来了：这就是 eBPF。

概念解析：eBPF（extended Berkeley Packet Filter）让用户态程序把一小段沙盒化字节码动态挂到 Linux 内核的特定钩子点上——网络收发包、系统调用、内核函数入口——不必重新编译内核，也不必加载传统内核模块。挂载前，内核里的 verifier 会逐条静态审查这段代码：禁止无限循环、必须在有限步数内终止、不能越界访问内存。通过审查的程序会被 JIT 编译成机器码，钩子触发时以接近原生的速度运行。程序通过 eBPF map——一种键值存储——与用户态或其他 eBPF 程序共享状态，比如计数器、连接跟踪表。这正是 Cilium、Falco、bpftrace 等云原生可观测性与网络工具的底层机制；OpenShift 上跑的 CNI（如 OVN-Kubernetes 部分加速数据路径）也仰赖它，在不停机、不改内核源码的前提下，给数据面钉上一张张可编程的哨站便条。

隐喻对应表

  • 港口 → Linux 内核（不能停机的运行系统）
  • 闸口 → hook point（网络收发包、系统调用等挂载点）
  • 便条 → eBPF 字节码程序
  • 老稽查员 → verifier（静态验证器，拒绝死循环与越界访问）
  • 便条刻进齿轮、被快速念出 → JIT 编译为机器码
  • 公用记事本 → eBPF map（用户态与内核态共享的键值存储）
  • 摘旧便条换新的、闸门不用动 → 动态加载/卸载 eBPF 程序，无需重新编译内核或重启

This harbor never closes. The tide doesn’t wait, and neither do the ships, so the harbormaster has one law that bends for nothing: the harbor may never stop, not for any reason. Gates stay standing, channels stay open, and the clock in the watch-house never loses a second.

Still, the harbormaster is forever having small, urgent notions — count how many ships flying a certain flag pass today, flag a certain cargo the moment it goes by. The trouble is that every gate in the harbor takes its rules from one master gear-engine down in the cellar. To give a single gate a new pair of eyes, you’d have to stop that engine, pull it apart, remesh the gears, and start it again. And the moment the engine stops, every gate in the harbor stops with it — which is exactly what the harbormaster would never grant.

So the harbor invented a post: the sentry clerk. Anyone wanting to watch a gate first writes a note and hands it to an old inspector famous for being impossible to please. This inspector waves nothing through that isn’t precise. The note may not say “circle back and wait” — no unbounded loops. It must be finished reading before the inspector reaches the bottom of the day’s manifest — a hard cap on steps. And it may not reach into a drawer that isn’t its own — no memory it wasn’t granted. Only a note that is orderly, and provably ends where it says it will, gets stamped and nailed to the sentry wall at the gate.

Once it’s nailed up, the inspector’s job there is done. The note gets read on its own, every single time a ship passes, at a speed that feels less like reading and more like the gears themselves already knew what to do — nothing fetched, nothing re-deciphered from someone’s handwriting. Whoever reads it doesn’t remember the whole yard, only writes down, in a shared logbook bolted to the wall, exactly the one thing it was told to track — “the 37th red-flag ship today,” say. The harbormaster can flip through that logbook any time. The sentry clerk cannot tear a page from it or slip in a false line.

Best of all: the day the harbormaster wants a different note, out comes the old one, up goes the new. The gate itself, the channel, the whole skeleton of the harbor — not one nail needs to move.

— By now you’ve probably placed it: this is eBPF.

What it is: eBPF (extended Berkeley Packet Filter) lets a userspace program attach a small piece of sandboxed bytecode directly to specific hook points deep in the Linux kernel — packet ingress and egress, syscalls, kernel function entry points — with no kernel recompile and no traditional kernel module to load. Before anything runs, the kernel’s verifier walks the code line by line: no unbounded loops, a hard bound on execution steps, no reaching past memory it was granted. Code that passes gets JIT-compiled into native machine instructions, so it fires at near-native speed every time the hook is hit. Programs share state with userspace, or with each other, through eBPF maps — key-value stores that back counters, connection-tracking tables, and more. This is the machinery underneath Cilium, Falco, and bpftrace, and much of modern cloud-native networking and observability — the CNI paths OpenShift clusters run on (parts of OVN-Kubernetes’s accelerated datapath, for instance) lean on it to nail programmable sentries onto the data plane without ever taking the system down.

Metaphor mapping

  • The harbor → the Linux kernel (a system that can never stop running)
  • The gate → a hook point (packet path, syscall, kernel function entry)
  • The note → an eBPF bytecode program
  • The old inspector → the verifier (rejects unbounded loops and out-of-bounds access)
  • The note read at gear-speed, no re-deciphering → JIT compilation into native machine code
  • The shared logbook → an eBPF map (key-value store shared between kernel and userspace)
  • Swapping the note without touching the gate → dynamically loading/unloading eBPF programs, no kernel rebuild or reboot