将内核内置模块替换为可加载模块

我开发了一个内核模块来管理 nf4 标签作为字符设备。

我在内核之外开发了这个模块，并在开发阶段将其编译为可加载内核模块（即 .ko）进行了测试。

一旦驱动程序功能正常且足够稳定，我就使用补丁将其插入 Linux 内核源代码 (v4.9.30)，以便将其构建为内核的一部分。

Here I'm in the situation where the module is loaded probed at boot by kernel as it's builtin and it appears into the device tree.

现在，我想尝试对驱动程序进行一些改进，但我不想将这些更改直接实现到内核中。

所以我想将驱动程序的代码集成到Linux内核中，但不要在启动时插入它。 为此，我刚刚更改了驱动程序的状态字段status = "disable";到设备树中，实际上该模块在启动时不再插入。

但是我无法插入已修改的可加载模块。我有一个ENODEV插入时，这是由于在探测函数中未找到 platform_device 造成的。

我不明白的是，当设备树除了状态字段值之外没有更改时，为什么找不到平台设备。

EDIT:添加有关情况的精确度

经过更多探索后，我必须明确我什至没有进入回调nf4_probe.

检查后platform_driver_probe实施（见here https://elixir.bootlin.com/linux/v4.9.30/source/drivers/base/platform.c#L660）进入 v4.9.30 内核源代码，错误似乎来自这里：

if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
    retval = -ENODEV;

通过从命令行检查设备树，我可以看到该设备被定义为目录/proc/device-tree/nf4tag存在并填充与设备树中的值相对应的值。

EDIT:在 @sawdust 的回答后添加关于问题目的的精确性

我显然误解了status=disable意味着该设备根本不存在于硬件配置中。尽管它只是描述了是否应该对驾驶员进行调查。

为了使我的目标更清晰，我明确表示我确实将驱动程序编码为正确的模块，并将其编译为我正在使用的内核的可加载模块。

但是我不想重新编译内核来测试我所做的每一个更改。所以我的目标是仅重新编译 .ko 直到进行修改，然后，一旦完成所有操作，使用补丁将这些修改添加到内置模块中。

通过这种工作方式，我可以重建 .ko 并将其插入到我的目标平台上，而不是为每次修改重新编译内核。

所以继续我的问题应该是：

如何用可加载模块替换内置模块而不重新编译内核以禁用内置模块？

除了禁用内置模块编译到内核之外，也许没有解决方案可以实现此目的。

我不明白的是，当设备树除了状态字段值之外没有更改时，为什么找不到平台设备。

你似乎误解了什么status = "disable"属性实际上意味着。
除此之外，这意味着内核应该“启动时没有插入它”，禁用的节点意味着该设备不是该设备的一部分current硬件配置全无。
驱动程序，无论是内置模块还是可加载模块，都不会被探测，因为它已针对当前配置被禁用。

如果您希望您的驱动程序（无论是内置模块还是可加载模块）处于当前配置，那么有一个status = "okay"其设备树节点中的属性。

IOW 设备树用于向内核描述当前的硬件配置。
不要尝试使用设备树来控制可加载模块（因为它不能）。

在这里，我所处的情况是，模块在启动时由内核加载，因为它是内置的，并且它出现在设备树中。

这个声明没有任何意义，因为您似乎同时将驱动程序描述为内置模块和可加载模块。
不一定需要内置驱动程序"loaded"为了调用它的探测例程。
由于驱动程序可以是内置的或可加载的，因此“加载”和“探测”是两个不同的阶段，不应混为一谈。

所以我想将驱动程序的代码集成到Linux内核中，但不要在启动时插入它。

您似乎将 Linux 内核的概念与源代码树混为一谈。
“驱动程序代码集成到Linux内核中”通常会被解释为内置驱动程序，即驱动程序链接到启动时加载的内核映像中，并且是其一部分。
而存储在内核源代码树中的驱动程序代码则无需指定它是内置模块还是可加载模块。许多驱动程序（和其他类型的模块）可以built可以是其中之一，并且是构建配置指定的。

如果您希望驱动程序成为可加载模块，则（而不是更改设备树）：

A。您需要将驱动程序编码为适当的模块；
b.你需要修改Kconfig文件来选择内置模块或可加载模块（即tristate versus bool选择规范）。
C。配置内核以将驱动程序构建为可加载模块。

作为可加载模块并在设备树中定义的设备驱动程序仍然可以在引导期间自动加载和探测。 您可能必须使用模块黑名单来防止这种情况。

** 附录 **

如何用可加载模块替换内置模块而不重新编译内核以禁用内置模块？

你不能。这就是为什么 Kconfig 强制您在可加载模块之间进行选择（m) 或内置 (y）如果您希望构建该驱动程序。

...然后，完成所有操作后，使用补丁将这些修改添加到内置模块中。

这是没有意义的，因为您只需要驱动程序源的单个副本即可构建可加载模块或驱动程序的内置版本。

通过这种工作方式，我可以重建 .ko 并将其插入到我的目标平台上，而不是为每次修改重新编译内核。

看来您如何将驱动程序集成到内核源代码中是有问题的。
您实际上做了什么来将驱动程序集成到内核源代码树中？
Which Kconfig and Makefile你修改了你的驱动程序吗？
您为驱动程序创建了哪些新的 CONFIG_* 符号？

是的，你必须“每次修改都重新编译”, but make足够聪明，可以只重建必要的部分。您可以通过使用进一步缩短内核重建时间make modules当您知道只有您的可加载驱动程序已被修改时。

结论

• 如果不重新编译内核以禁用内置模块，就不可能使用树外可加载模块。

BUT

• 仅重新编译内核一次tristate at M并将内核引导行上的模块列入黑名单成功。
• 仅重新编译内核一次tristate at n成功。

因此内核必须至少重新编译一次，但是这样就可以使用编译为可加载模块的树外驱动程序，而无需删除集成到 Linux 源代码中的代码。