Why don’t we rename Linux to BPF-kernel?

题目来自lwn的一个带有嘲讽的针对性评论。该文链接如下：
https://lwn.net/Articles/808503/

针对该评论的回应如下：

A heavy reliance on BPF is not a bad thing in and out of itself.

It makes me remember the GCC scenario: it made pluggability quite hard, on purpose, due to a political fear of plugins and GNU losing control. Meanwhile, LLVM, heavily encouraged extensibility: static analysis, R&D in compilers and programming-languages, etc.

In around 10 years or so, a lot of new programming languages and static analysis tools began using LLVM exclusively, and GCC has taken a back seat.

TLDR: no need to hate BPF here. It’s encouraging a lot of R&D in the kernel and surrounding plumbing layer. Let the technology progress freely…

同时，我们来看另一个更加刁钻的针对eBPF的评论，来自一篇关于5.6 merge window的lwn：
https://lwn.net/Articles/810780/

BPF == Biggest Possible Fuckup.

幸运的是，回应是文明且讲道理的：

This kind of comment is really not helpful to anybody. LWN comments are far better when we’re not just tossing random childish insults around; could I ask you (and others!) to please stop doing that?

当一个新概念或者一个很酷的新做法被人首次提出或者使用后，两个派别就形成了，有人盲目吹捧，有人盲目打压，但无论如何，对这个新的概念或者新的做法无法产生任何影响。

这个新的概念就是eBPF，它源自于一个很老的概念，BPF。

这个新的做法即大量eBPF程序灌入内核产生作用。

我们来看看eBPF到底会如何。

eBPF进入Linux内核已经有段时间了，一直到5.6版本内核，它都是以不断 蚕食 的方式在内核中不断加作用点，似乎这个过程会一直持续下去。

对于Linux内核原教旨主义者，eBPF的这种方式无异于内核身上长了恶性肿瘤并且开始扩散。但在我看来，即便是eBPF不断蚕食内核，它给内核带来的影响也是次要的，它并没有撼动Linux内核的编程方式。

并且，这种方式是不可持续的，当eBPF的调用点达到一个临界值时，内核的性能将会严重受到影响，并且代码也将变得凌乱不堪，至少，Linus会叫停这种行为。

正如本文开头针对嘲讽的正儿八经的评论：

• A heavy reliance on BPF is not a bad thing in and out of itself.

并且，评论者用GCC举了例子。

所以，eBPF似乎并不会如很多人担心的那样，鸠占鹊巢，成为内核之base。

但是，Linux 5.6合并窗口里的一个特性，让事情起了变化：

The new BPF_PROG_TYPE_STRUCT_OPS BPF program type allows a BPF program to fill in where a function pointer would otherwise be used in the kernel; this feature was introduced with this commit. The first use of this feature is to allow the writing of TCP congestion-control algorithms in BPF; this commit adds a DCTCP implementation as an example.

虽然该feature被列入networking板块，但它的影响却是全局的。详情可以参见下面的lwn：
https://lwn.net/Articles/811631/
https://lwn.net/Articles/809092/
我自己也写了一篇相关的：
https://blog.csdn.net/dog250/article/details/104431647

换句话说，TCP CC算法只是该eBPF新特性戳入的第一刀。通过文章我们可以看出，该特性并不是仅仅针对TCP CC的，它有更加宏伟的目标：

• BPF CO-RE(Compile Once – Run Everywhere)
  参见：http://vger.kernel.org/bpfconf2019_talks/bpf-core.pdf

BPF_PROG_TYPE_STRUCT_OPS旨在实现目前只能由内核模块甚至代码本身实现的代码。做到可以编写真正的与内核版本无关的代码。 这就是 eBPF BPF_PROG_TYPE_STRUCT_OPS type 的鸿鹄之志。

这与之前只是松散的在人们认为关键，常用的hook处打点调用eBPF程序完全不同，这是一个通用的方案，它可以用eBPF字节码替换内核空间的各类回调函数，这才是真正的 内核可编程 。

…

在BPF_PROG_TYPE_STRUCT_OPS被引入之前，eBPF充其量只让内核变得 可点缀，可圈点，可修理， 然而从此以后，内核越来越变得真正的 可编程。

原教旨主义者当然不能接受这股黑云压城城欲摧之风，但实用主义者却喜迎这山雨欲来风满楼之喜，遂分离了两大阵营。

我始终还是认为eBPF就是把瑞士军刀，而不会成为AK-47，如果非要它成为AK-47，势必要对Linux内核进行比较大的结构上的重构。Linux本身就是一个宏内核，却无论如何也不会被eBPF变成微内核的，至少是非常难。

目前，迄至5.6内核，eBPF所能完成的事情，主要包括四类：

• 实现跟踪和探测。这个基本上是绝大多数人对eBPF的认知。
• 实现网络功能。这个做网络的才知道，比如XDP，socket查找之类。
• 实现内核安全策略。这个也是比较小众了，比如Seccomp。
• 实现内核回调函数。比如TCP CC。

但是，Linux内核的核心组件是进程管理，内存管理，文件系统，设备管理这些，eBPF在这些核心领域能有多大作为，还有待观测。

至于网络协议栈，其实它更像是一个应用支撑库，而不是真正意义上的内核组件，网络协议栈永远都是偏业务的，所以人们折腾网络协议栈的机会自然就比较多，所以人们自然在eBPF对网络的支持方面也会优先考虑。

另外，我十分乐意看到eBPF在Windows上的支持，对于Windows这种闭源系统，写内核驱动以及调试的门槛也是比较高，所以Windows更适合用eBPF去做点事。

谈谈国内互联网公司对eBPF的态度。

大多是暗中观察，个别是根本无视。这也是有原因的。

互联网公司操作系统内核版本无法跟进到最新版本，甚至无法跟进到eBPF全面支持的版本，这意味着eBPF在这些公司是不可online使用的，那么就只能沦为一种所谓的技术储备。

此外，业务部门非常diss所谓的技术储备，因为在业务部门或者业务支撑部门，任何东西如果不能带来online的业务价值，在结果上便是无绩效的，这对自己以及团队的短期KPI非常不利。

那么，既没有动机，又没有收益，又无法所见即所得，谁又会去完成技术储备的？看来也只有基础设施支撑部门了，但是基础设施团队又很难去贴合业务做case by case贴身适配，也会尴尬。

最终，在使用到eBPF技术的时候，在存在上线上量快速迭代的压力下，大家也就只能拿来主义，囫囵吞枣了。

不过，无论怎样，大风向是不会改变的，你只需要做好选择和准备，你是用eBPF仅仅做trace/probe呢，你是用eBPF做网络定制开发呢，还是做点别的？你可以diss，但千万不要不care，飓风刮起的时候，树欲静而风不会停止，给多少钱都不会停。

我个人的观点，还是倾向于用eBPF去实现一些功能，而不是仅仅用来做trace/probe/信息统计。

浙江温州皮鞋湿，下雨进水不会胖。