On 01.04.2020 23:20, Heiner Kallweit wrote: > 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 > Any feedback? Thanks, Heiner