我对kernel的敬畏之心在逐渐退散

 经过这些天各式各样代码的阅读，userspace和kernel的，C++的和rust的，我一直以来崇拜linux kernel的心境逐渐在变化。

之前的half truth

1. kernel代码坚不可摧
   我依然认为kernel的代码质量很高，因为more eyes on it。code review的都是领域的大神，同时发布之后的代码很难像发布service一样快速迭代，长期生长在这样严格的环境，maintainer必然倾向于维护高质量的代码。
2. kernel代码没有tech debt，即使有，也会很快消灭
   从list的head和entry在逐渐用field name区分的趋势上看，tech debt更有可能在kernel中生存更久，因为骨灰级的maintainer才可能推动这样伤筋动骨的改动，但是一旦有了这样的能力，恐怕这些readability的改进对maintainer来说已经不再有多少impact。
3. kernel代码的开发的方法论应该推广到所有非kernel的领域
   kconfig language很赞，但我怀疑在其他领域是否值得这样一个系统。kernel代码的作者来源更广，也许github不是最好的选择，但不代表所有代码都达到这个规模。同时github等代码hosting的提供者能不能继续改进从而能为kernel这个级别的代码库提供服务？我觉得并非不可能，而是github本身动力不足，毕竟这样规模的代码库恐怕也不多。
4. kernel的算法和结构远超userspace
   从代码并发的需求上，kernel的代码的客观需求更加强烈。毕竟userspace的application很多没有必要部署在三位数的core的机器上。一个application需要64core的机器很罕见，通常的部署方式也更倾向于frontend做loadbalance，后面的application有多个replica。很多时候，即使软件可以scale到1M connections，为了减少部署时的可控和impact，更多时候是使用多个replica，而每个replica负责xxK connections。然而kernel的代码必须要支持最新的处理器，因为不能让一个baremetal上面跑两个kernel。
   
5. kernel的代码更超前
   从某种意义上，kernel的代码需要从device driver的角度支持最新的硬件，而应用层依赖于更稳定并且陈旧的api。不过，反过来说，kernel和application都是老式api的奴隶。即使是新的device driver也需要向老的API妥协。
6. kernel推动硬件的发展
   其实应该说kernel代表userspace和kernelspace一起推动硬件的发展。从DPDK上就可以看出来，各种bypass kernel的方案，不是完全抛弃kernel，而是让kernel提供更薄的包装，让userspace可以有更大的操作空间去使用硬件的API。相信这个layer变薄之后，会诞生更多来自userspace的硬件需求。