4. 内在驱动
由以上简要的回顾和梳理可见，内核开发者们所不断寻找的是一种充分表达能力的动态机制，进而打破内核和用户态的壁垒（至少在逻辑层面），从而实现一种自由、直接的需求实现。技术成为内核开发者们锋利的工具，不断突破限制，揭示事物的本质。
BPF技术的出现和发展，从时间尺度来说并不长，但是从其内在的驱动来说，有着复杂的动因，是很多因素就和在一起的必然结果。由于其复杂性，从任何一个孤立的角度进行分析都是不充分，只有从各个不同的角度分析，才可以体会出不同的趣味。
通过探寻其深层次的原因，可以梳理出更加清晰的发展脉络，从而可以更好地展望BPF及其相关技术领域的未来发展。为我们学习、研究和加入BPF的发展打下基础。
本文试着从复杂性、微内核化两个方面，分析BPF发展的内在动力。
内核的发展历史就是一个复杂性不断递增的历史，因此内核的发展也是不断控制复杂性、维持内核代码的可理解性的过程。因此，内核的开发始终坚持一个原则，就是机制与策略的分离。
在不同时期，如何进行机制与策略的分离，有这不同的答案。随着技术和应用的不断发展，维持这一原则的的难度是不断增加的，需要更新的思想、更先进的技术才能支撑。或者也可以说，正因为内核的发展过程中，始终坚持了这个原则，所以才不断有影响深远的基础技术的出现。
我相信，要实现定制与动态，有很多不同的方案。但我认为BPF的出现是最佳的选择，使内核的发展有了应对未来变局的基础。
这是BPF出现的契机，也是其未来快速发展的动力。
4.1代码规模问题
Linux项目发展至今，其代码总量早已超过千万，是一个非常庞大的项目。
注：来源https://www.phoronix.com/misc/linux-eoy2019/lines.html
由统计数据可以看出，Linux项目的复杂度（从代码量角度）一直在不断增长。
4.2软件结构的复杂
整个软件系统，从应用程序到内核是一个繁杂的层次结构，又由于模块之间的交叉，实际的运行流程是一个复杂的有向图结构。
以完成一次简单的文件操作为例，首先应用程序需要open一个文件，这首先会运行到某种运行时库，完成资源分配、接口转换等等处理。然后，流程才会到系统调用这一层。
系统调用中，由VFS解析文件路径信息，找到对应的文件系统信息。再由具体的文件系统完成文件打开的操作。
这其中至少涉及到了应用程序、运行时库、系统调用、VFS、文件系统等多个层次。如果再细分的话，还涉及到用户态内存管理，内核态内存管理、权限管理、命名空间管理、句柄管理、缓存管理、锁、钩子等次级模块。
目前Linux支持的文件系统至少已经达到七十多种，有基于本地存储设备的、基于网络的、分布式的、基于内存的、虚拟的等等。有的文件系统在内核态实现，有的在用户态实现。
另外，C语言的条件编译，可以针对使用场景选择适合的代码编译。每一个条件编译选项就是对现实条件的一个考量。从Linux整个源码树中使用的条件编译选项的数量，也可以反映出Linux整个源码的复杂度。对Linux 5.10的源代码粗略统计，条件编译选项已经多达18000多个；而在6.1版本中，已经达到了19000多个。
4.3业务系统的复杂
在虚拟化技术以前，不同应用场景的业务系统的结构差异，主要表现为平面性的拓扑结构的差异，比如：对等式的、分布式的、客户服务器模式的等等，由于网络拓扑结构的不同、节点承担的业务角色的不同，形成了各种各样的业务系统。
在虚拟化技术出现后，云计算迅猛发展，云成为了信息系统的基础设施。业务系统的差异不仅仅体现在横向拓扑结构上，其自身逻辑的深层组成也是非常复杂。它可以运行在真实计算机上也可能在虚拟机上，可能在一个独立的命名空间，也可能和别的业务共享。不同业务模块之间的联系有可能是直接的，也可能在无法感知的情况下被层层嵌套。
业务系统的复杂性，体现在业务的复杂性与业务系统的复杂性两个方面。业务的复杂，导致我们需要对业务系统进行分层设计，需要有定制化的能力，需要有运营与持续开发并行的能力。上线前的产品级的开发很重要，但是上线后的业务级的持续定制和开发同样重要。复杂的业务必然导致复杂业务系统的产生，如何以一个统一的、足够强大的方式来解决复杂性问题，使复杂业务系统的复杂性是可以拆解的、可管理的，就非常重要。
4.4维护限制的要求
Linux系统已经规模化运行在各种类型的设备上，每一个商业系统，在其运行期间都是需要进行维护的。
对于大型的服务器系统，承载在成千上万的在线业务，是不能中断服务的，需要在线的定制能力。
对于个人终端，每个人的使用习惯不同，如何使每个用户都能获得最佳的使用体验，需要数据分析和个性化的定制能力。
对于散布在各处角落的边缘节点乃至物联网设备，需要内核提供更智能的介入方法，使维护人员能够远程完成对大量设备的维护工作。
