我已经看到了用户空间版本的ebpf(运行时，汇编程序，反汇编程序)正在开发中(uBPF, rbpf)。
这些替代方案是否与eBPF程序类型(网络、可观察性和安全性)关注相同的目标?
eBPF的主要优点之一是它在内核中运行代码。可观察性、内核内数据聚合、早期数据包处理:这一切都发生在内核空间中。所以这个问题听起来很合理:为什么要创建uBPF或rbpf ?
我认为它们主要是作为原型创建的。uBPF在eBPF历史上很早就被引入，它可能是eBPF解释器和x86_64 JIT在用户空间中的概念验证实现。我编写了rbpf，它强烈地基于uBPF，我的主要目标是更加熟悉两件事:eBPF和Rust。
我一直很好奇人们能用它做什么。说实话，没有那么多用户。rbpf最大的用户可能是来自Solana的人，他们实现了一些区块链工具，并在eBPF机器上运行智能合约。我过去有过的另一个用例是调试一些eBPF字节码，因为在用户空间解释器中很容易有断点(相比之下，常规内核eBPF的运行时调试此时相当有限)。
uBPF更成功，并被用作其他项目的基础，如DPDK作为过滤库或Oko, Open vSwitch的扩展(都是关于高性能网络处理的)。[编辑2021年8月]最近，它被选择作为eBPF在Windows上实现的eBPF运行时(参考:公告，我的分析)。
如您所见，拥有这些用户空间eBPF机器的兴趣完全取决于您如何使用它。它们可用于运行eBPF程序，它们本身没有特定的关注点，但如果您有用例，它们可以提供帮助。在这方面，uBPF和rbpf的一个特殊之处在于它们的许可证(Apache、MIT):它们不在GPL之下，这意味着您可以在更多的项目中重用它们，包括专有项目。对于内核代码，情况并非如此。对于那些用户空间的eBPF机器来说，一个很大的限制是，它们在内核中发生的事情往往是相当过时的，在内核中事情发展得很快。它们没有可靠的验证者，因此您不能断言程序的安全性或安全性。它们几乎不支持eBPF映射，它们不支持函数调用，也不支持BTF，甚至不支持最新的eBPF指令。其中一些可以添加，但这需要一些工程上的努力和时间。[编辑2021年8月]由于微软为它的eBPF实现做出了贡献，现在uBPF得到了很多活动。他们还使用了用户空间验证器，即PREVAIL。