Mistakenly sent it to linux-module instead of linux-modules. -------- Forwarded Message -------- Subject: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek) Date: Wed, 1 Apr 2020 23:20:20 +0200 From: Heiner Kallweit To: Lucas De Marchi , Jessica Yu CC: Linux Kernel Mailing List , linux-module@vger.kernel.org, netdev@vger.kernel.org Currently we have no way to express a hard dependency that is not a symbol-based dependency (symbol defined in module A is used in module B). Use case: Network driver ND uses callbacks in the dedicated PHY driver DP for the integrated PHY (namely read_page() and write_page() in struct phy_driver). If DP can't be loaded (e.g. because ND is in initramfs but DP is not), then phylib will use the generic PHY driver GP. GP doesn't implement certain callbacks that are needed by ND, therefore ND's probe has to bail out with an error once it detects that DP is not loaded. We have this problem with driver r8169 having such a dependency on PHY driver realtek. Some distributions have tools for configuring initramfs that consider hard dependencies based on depmod output. Means so far somebody can add r8169.ko to initramfs, and neither human being nor machine will have an idea that realtek.ko needs to be added too. Attached patch set (two patches for kmod, one for the kernel) allows to express this hard dependency of ND from DP. depmod will read this dependency information and treat it like a symbol-based dependency. As a result tools e.g. populating initramfs can consider the dependency and place DP in initramfs if ND is in initramfs. On my system the patch set does the trick when adding following line to r8169_main.c: MODULE_HARDDEP("realtek"); I'm interested in your opinion on the patches, and whether you maybe have a better idea how to solve the problem. Heiner