Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: RFC: Handle hard module dependencies that are not symbol-based
 (r8169 + realtek)
From:   Heiner Kallweit <hkallweit1@gmail.com>
To:     Lucas De Marchi <lucas.demarchi@intel.com>,
        Jessica Yu <jeyu@kernel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-modules@vger.kernel.org,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>
References: <f8e3f271-82df-165f-63f1-6df73ba3d59c@gmail.com>
Message-ID: <88aabe57-b38f-2200-05ab-7f54bda274fe@gmail.com>
Date:   Wed, 8 Apr 2020 23:37:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <f8e3f271-82df-165f-63f1-6df73ba3d59c@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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