有时内核开发者会发现他们在竞争，都想把他们各自的特定功能版本加入到内核中。但有时开发者会发现他们一直在非常相似的方向上工作，而他们没有一起工作的唯一原因是他们根本不知道彼此的存在。

最近，Jian-Hong Pan 询问大家是否对一个他一直在开发的 LoRaWAN 子系统感兴趣。LoRaWAN 是一种商业网络协议，实现了低功耗广域网 (LPWAN)，允许事物之间进行相对缓慢的通信，通常是电话传感器和其他物联网设备。Jian-Hong 发布了一个链接，指向他目前为止完成的工作：https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN。

他特别想知道“如果 LoRaWAN 将被 Linux 接受为一个子系统，我们现在是否应该将定义添加到相应的内核头文件中？” 他提出这个问题的原因是，每个定义都有自己的编号。将它们添加到内核中意味着与任何未来的 LoRaWAN 子系统相关的编号在开发期间将保持不变。

然而，Marcel Holtmann 解释了这个过程

当您将您的 LoRaWAN 子系统提交给 netdev 进行审查时，请包含一个补丁，该补丁添加了这些新的地址族定义。只需选择下一个可用的即可。在您的工作被上游接受之前，不会预先分配编号。这意味着，如果其他地址族在您的之前合并，则编号可能会更改。因此您必须不断更新。glibc 最终将遵循内核分配的编号。

与此同时，Andreas Färber 说他自己也在致力于支持相同的协议，并给出了他自己的概念验证仓库的链接：https://github.com/afaerber/lora-modules。

在了解到 Andreas 的工作后，Jian-Hong 的回应是：“哇！太棒了！我交到新朋友了 :)”

公众对话到此结束。他们两人无疑已经汇集了他们的力量，并将产生一个新的补丁，比他们任何一个人单独完成的都要好。

对我来说有趣的是，有些项目比其他项目更易于合并。这似乎与开发人员的个性关系不大，而更多地与内核特定领域中的利害关系有关。一个新的负载均衡算法可能会改善某些用户的用户体验，但会使其他用户的用户体验恶化，这取决于他们的特定习惯。鉴于不可能将许多不同的负载均衡器都放在内核中，两位开发人员如何解决他们自己关于哪种方法更好的问题？这类问题曾经引发旷日持久的争论。另一方面，支持特定的协议或特定的外围设备要容易得多。一方面来说，在内核中拥有几个竞争驱动程序通常不是问题，至少在短期内是这样，只要它们不深入挖掘核心内核行为即可。开发人员可以在实际用户群上测试他们的想法，看看哪些真正有效，哪些无效。当这种自由消失时，您就会更接近真正的速度问题和真正的安全问题。

注意：如果您在上面被提及并希望在评论区上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。