翻译《SIGQUIT 内核中的 QMI/Gobi 管理》文章

本文章翻译自QMI/Gobi management in the kernel: qmi_wwan or GobiNet? | SIGQUIT

未经过原作者许可，如果存在版权问题，联系我删除。本次翻译仅仅作为知识分享和传播，不进行任何盈利活动。

内核中的 QMI/Gobi 管理：qmi_wwan 还是 GobiNet？

6月11日

发布者aleksander

介绍

Gobi芯片组是高通开发的移动宽带调制解调器，目前被许多不同的制造商使用，包括 Sierra Wireless、中兴通讯、华为，当然还有高通自己。

这些设备通常会在 USB 层公开多个接口，然后每个接口将作为不同的“端口”（名称不正确，但我想这样更容易理解）发布到用户空间。一些接口将允许访问调制解调器中的串行端口（例如 ttys），这将允许用户使用 AT 协议和 PPP 会话执行标准连接程序。通过串行端口使用 PPP 会话的主要问题是，它很难（如果不是完全不可能的话）处理 3G 以上的数据速率，如 LTE。因此，除了这些串行端口之外，Gobi 调制解调器还提供对控制端口（使用 QMI 协议）和网络接口（将其视为标准以太网接口）的访问。然后可以完全通过 QMI 执行连接程序（例如提供 APN、身份验证……），然后用户空间可以使用更方便的网络接口进行实际数据通信。

长期以来，在 Linux 内核中使用这种 QMI+net 对的唯一方法是使用Qualcomm 或其他制造商提供的GobiNet驱动程序，以及他们开发的用户空间工具（其中一些是免费/开放的，一些是专有的）。幸运的是，几年前 Bjørn Mork 开发了一种新的qmi_wwan驱动程序并合并到上游内核中。这个新驱动程序提供对 QMI 端口和网络接口的访问，但比原始的 GobiNet 驱动程序简单得多。范围大大缩小，以至于 GobiNet 驱动程序在内核空间中执行的大部分工作现在必须由用户空间应用程序来完成。现在至少有 3 种不同的用户空间实现允许通过 qmi_wwan 端口使用 QMI 设备：ofono、uqmi 以及libqmi。

但问题仍然存在。我应该使用什么？上游 qmi_wwan 内核驱动程序和 libqmi 等用户空间实用程序？还是制造商提供的树外 GobiNet 驱动程序和用户空间实用程序？我可能完全有偏见，但我会尝试通过指出它们的主要区别来比较这两种方法。

注意：您可能想先阅读我之前写的“ libqmi 简介”帖子。

树内 vs 树外

qmi_wwan 驱动程序在上游 Linux 内核（树内）中维护。与 GobiNet 相比，仅这一点就是一个巨大的优势。内核更新可能会修改它们为不同驱动程序公开的内部接口，并且由于与所有其他驱动程序位于同一源中，qmi_wwan 驱动程序也将无需进一步努力即可获得这些更新。每当您安装内核时，您都知道您将准备好适用于同一内核版本的 qmi_wwan 驱动程序，因此它的使用非常简单。qmi_wwan 驱动程序还包含对所有供应商的基于 Gobi 的设备的支持，因此无论您使用的是 Sierra Wireless 调制解调器还是华为调制解调器（仅举几例），该驱动程序都能够让您的设备在内核中按预期工作。

广告

举报此广告

GobiNet 则完全不同。GobiNet 不止一个：每个制造商都有自己的 GobiNet。如果您使用的是 Sierra Wireless 设备，您可能希望使用他们维护的 GobiNet 驱动程序，例如，特定的 VID/PID 对已经包含在驱动程序中；或者更深入一点，以便驱动程序知道应该使用哪个 QMI/WWAN 接口号（不同的供应商有不同的 USB 接口布局）。除了需要寻找最适合您设备的 GobiNet 驱动程序的问题之外，在树外维护驱动程序意味着他们需要为非常长的一组内核版本提供一组源代码。因此，源代码中充满了 #ifdef，根据目标内核版本启用/禁用不同的代码路径，因此维护它比仅在树内维护要复杂得多。

注意：有趣的是，我们已经看到首先在 qmi_wwan 中实现的修复被“移植”到 GobiNet 变体中。

复杂

qmi_wwan 驱动程序很简单；它只会获得一个 USB 接口，并将其拆分为支持 QMI 的 /dev/cdc-wdm 端口（通过 cdc-wdm 驱动程序）和 wwan 网络接口。由于内核仅提供往返设备的基本传输，因此用户空间需要完全管理 QMI 协议，包括服务客户端分配/释放以及整个内部 CTL 服务。但请注意，这不是问题；像 libqmi 这样的用户空间工具可以很好地完成这项工作。

GobiNet 驱动程序非常复杂。该驱动程序还公开了一个控制接口（例如 /dev/qcqmi）和一个网络接口，但通过内部 CTL 服务完成的所有工作都是在内核级完成的。因此，不同服务的所有客户端分配/释放实际上都是在内部执行的，而不是暴露给用户空间。用户只需通过 ioctl() 调用即可请求客户端分配，客户端释放将在内核中自动管理。一般来说，永远不建议使用如此复杂的驱动程序。随着驱动程序复杂性的增加，出现错误的可能性也会增加，驱动程序崩溃可能会影响整个内核。引用 Bjørn 的话，设备驱动程序越小，系统就越强大。

注意：某些 Android 设备还通过 GobiNet（隐藏在内核和 RIL 中的所有内容）支持支持 QMI 的芯片组。不过，在这种情况下，您可能会看到共享内存也可用于与 QMI 设备通信，而不是 /dev/qcqmi 端口。

设备初始化

与 Gobi 设备通信时要做的首要任务之一是设置它（例如，决定在网络接口中使用哪种链路层协议）并确保调制解调器已准备好使用 QMI。对于 GobiNet 驱动程序，这一切都是在内核空间中完成的；而对于 qmi_wwan，一切都可以在用户空间中管理。libqmi 库允许在设备初始化期间执行多项操作，包括设置要使用的链路层协议。例如，Sierra Wireless 的一些型号（如新款 MC7305）默认公开一个配置为使用 802.3（以太网报头）的 QMI+网络接口（#8）和另一个配置为使用原始 IP（无以太网报头）的 QMI+网络接口（#10）。使用 libqmi，我们可以将第二个切换为使用 802.3，这是 qmi_wwan 所期望的，从而允许我们同时使用两个 QMI+网络对。

多个进程对话 QMI

qmi_wwan 的一个问题是，在给定时间内只有一个进程能够使用控制端口。相反，GobiNet 驱动程序允许多个进程同时访问设备，因为每个进程将直接从内核分配具有不同客户端 ID 的不同 QMI 客户端，因此不会相互干扰。为了解决这个问题，libqmi（自 1.8 版起）进行了扩展，以实现“qmi-proxy”进程，该进程将是唯一访问 QMI 端口的进程，但它允许不同的进程同时与设备通信（通过在连接的对等体之间共享和同步 CTL 服务）。

用户空间库

GobiNet 驱动程序旨在与用户空间中的 Qualcomm C++ GobiAPI 库一起使用。在此库的基础上，其他制造商（如 Sierra Wireless）提供了其他库来使用其设备的特定功能。此 GobiAPI 库将自行处理所有所需的 ioctl() 调用，例如分配新客户端，还将提供高级 API 来访问设备中的不同 QMI 服务和操作。

对于 qmi_wwan 驱动程序，如前所述，有几种实现可让您与设备进行 QMI 通信。我维护的libqmi就是其中之一。libqmi 提供了一个基于 GLib 的 C 库，因此它公开了对象和接口，这些对象和接口可用于访问任何类型的设备中最常用的 QMI 服务。CTL 服务（由 GobiNet 在内核中管理的内部服务）将由 libqmi 内部管理，因此对于库的用户来说，它基本上是隐藏的。

注意：目前还不能将 GobiAPI 与 qmi_wwan 混合使用，也不能将 libqmi 与 GobiNet 混合使用。因此，目前还不能在配备支持 QMI 芯片组的 Android 设备中使用 libqmi 或 qmicli。

用户空间命令行工具

我真的不知道有任何通用命令行工具是为与 GobiNet 驱动程序一起使用而开发的（好吧，固件加载器应用程序，但这些不是通用的）。缺少命令行工具可能是因为，由于 QMI 客户端是由 GobiNet 内核自动发布的，因此很难（如果可能的话）让 QMI 客户端保持分配状态并通过执行操作并退出的命令行工具反复重复使用它。

但是，使用 qmi_wwan，由于客户端不会自动释放，因此命令行工具更容易处理。libqmi 项目包含一个qmicli工具，该工具能够在程序的每次运行中执行独立的 QMI 请求，甚至在需要时在每次运行中重复使用相同的 QMI 客户端。这在启动连接时尤其重要，因为只要连接处于打开状态，执行“启动网络”命令的 WDS 客户端就必须保持注册，否则连接将被断开。

新固件加载

将新固件加载到基于 QMI 的设备的过程并不简单。它涉及 QMI 级别的几个交互，以及基于 QDL 的固件下载到设备（类似于 gobi_loader 对 Gobi 2K 所做的工作）。遗憾的是，在使用 qmi_wwan 及其用户空间工具时，还没有办法执行此操作。如果您需要更新设备的固件，唯一的选择就是使用 GobiNet 驱动程序和供应商提供的程序。

[2016 年 12 月更新]自 libqmi 1.18.0 起，可以使用新的qmi-firmware-update 工具通过 libqmi 和 qmi_wwan 完成固件更新操作。

支持

GobiNet 驱动程序的优点之一是，如果使用该内核驱动程序，每个制造商都将（应该）为其设备提供直接支持。实际上，有些供应商仅在其驱动程序是正在使用的驱动程序时才为硬件提供支持。因此，我认为如果公司希望依赖供应商提供的支持，GobiNet 可能是一个不错的选择，但对于恰好在其系统中拥有此类设备的标准用户来说，GobiNet 可能不是一个好选择。

但是，即使它不是官方支持，如果您的 QMI 设备遇到问题，您仍然可以联系libqmi 邮件列表；或者联系为 qmi_wwan 驱动程序和 libqmi/qmicli 集成需求提供商业支持的公司或个人（例如我！） 。