我猜社区还没有准备好分离 HAL。像 libnml 这样更底层的东西可能是了解它如何进行的一个很好的练习。如果没有采用该技术的人，那么我们就可以保持原样。只是，我们已经知道 HAL 有 LinuxCNC 外部的采用者。这实际上意味着我们也有 libnml 的外部采用者，但我们还没有挑出那个库。

@hansu，能否请您将其列入下一次 Open Mike 会议的议程？

@hansu，能否请您将其列入下一次 Open Mike 会议的议程？

✔️

显然，我不同意。我们应该发现您提到的任何一点是否以某种方式受益于 LinuxCNC 在源代码树之外。从我对 libnml 的看法来看，这在很大程度上是不变的，也是项目中最古老的代码库：它已经分离，只是没有正式分离。

实际上（一度）有很多关于取代 NML 的讨论。
如果您认真对待将其分离的工作，那么讨论更换它可能是恰当的。

machinekit 的目标是用基于其他技术 zeromq 的东西替换 nml。对我的个人邮件列表存档进行本地搜索，它看起来像“zeromq”作为搜索词会出现许多老式帖子。

machinekit 的目标是用基于其他技术 zeromq 的东西替换 nml。对我的个人邮件列表存档进行本地搜索，它看起来像“zeromq”作为搜索词会出现许多老式帖子。

你和 Seb 不是也曾在一次盛会上开始过类似的活动吗？

Seb 和我开始的事情是 LinuxCNC 的“纯 C”API，但它不一定摆脱 libnml ..这是关于“最原生的 API”仅是 C++ 的问题，这不适合接触脚本语言以及（今天）流行的年轻语言，如 Rust。它并没有走多远。

我发现https://stackshare.io/stackups/mqtt-vs-zeromq很有帮助。我不知道看到 libnml 被完全删除是有动机的。

Michael Haberler 热衷于用（我认为）ZeroMQ 取代 NML。或者也许是 Redis。或者可能是两者的结合。
（这是在 Machinekit 拆分之前）
如果您在电子邮件存档中搜索 0MQ、zeromq 和 redis，您应该能够获得一些上下文。