linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Petr Mladek <pmladek@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-modules@vger.kernel.org,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	live-patching@vger.kernel.org
Subject: Re: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek)
Date: Wed, 15 Apr 2020 11:16:12 +0200	[thread overview]
Message-ID: <20200415091612.GA384@linux-8ccs> (raw)
In-Reply-To: <e38f3115-1e77-ebce-423b-8ea445be9e0d@gmail.com>

+++ Heiner Kallweit [14/04/20 18:20 +0200]:
>On 14.04.2020 18:09, Jessica Yu wrote:
>> +++ Heiner Kallweit [10/04/20 00:25 +0200]:
>>> On 09.04.2020 02:02, Lucas De Marchi wrote:
>>>> On Wed, Apr 01, 2020 at 11:20:20PM +0200, 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.
>>>>
>>>> Could you expand on why softdep doesn't solve this problem
>>>> with MODULE_SOFTDEP()
>>>>
>>>> initramfs tools can already read it and modules can already expose them
>>>> (they end up in /lib/modules/$(uname -r)/modules.softdep and modprobe
>>>> makes use of them)
>>>>
>>> Thanks for the feedback. I was under the impression that initramfs-tools
>>> is affected, but you're right, it considers softdeps.
>>> Therefore I checked the error reports again, and indeed they are about
>>> Gentoo's "genkernel" tool only. See here:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=204343#c15
>>>
>>> If most kernel/initramfs tools consider softdeps, then I don't see
>>> a need for the proposed change. But well, everything is good for
>>> something, and I learnt something about the structure of kmod.
>>> Sorry for the noise.
>>
>> Well, I wouldn't really call it noise :) I think there *could* be
>> cases out there where a establishing a non-symbol-based hard
>> dependency would be beneficial.
>>
>Thanks for the encouraging words ;)
>
>> In the bug you linked, I think one could hypothetically run into the
>> same oops if the realtek module fails to load for whatever reason, no?
>
>Basically yes. Just that it wouldn't be an oops any longer, r8169
>would detect the missing dedicated PHY driver and bail out in probe().
>
>> Since realtek is only a soft dependency of r8169, modprobe would
>> consider realtek optional and would still try to load r8169 even if
>> realtek had failed to load previously. Then wouldn't the same problem
>> (described in the bugzilla) arise?  Maybe a hard dependency could
>> possibly come in handy in this case, because a softdep unfortunately
>> implies that r8169 can work without realtek loaded.
>>
>Right. Even though kmod treats a softdep more or less like a harddep
>with regard to module loading, it's called "soft" for a reason.
>Relying on a softdep to satisfy a hard dependency doesn't seem
>to be the ideal solution.

Hm, I wonder how many other drivers do this. It may be worth auditing
all current MODULE_SOFTDEP() users to see if there are others also
using it to mean harddep (i.e., it's actually a non-optional
dependency) rather than softdep. Something to add on my todo list.

Jessica

      reply	other threads:[~2020-04-15  9:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f8e3f271-82df-165f-63f1-6df73ba3d59c@gmail.com>
2020-04-01 21:22 ` Fwd: " Heiner Kallweit
2020-04-08 21:37 ` Heiner Kallweit
     [not found] ` <20200409000200.2qsqcbrzcztk6gmu@ldmartin-desk1>
2020-04-09 22:25   ` Heiner Kallweit
2020-04-14 16:09     ` Jessica Yu
2020-04-14 16:20       ` Heiner Kallweit
2020-04-15  9:16         ` Jessica Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200415091612.GA384@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pmladek@suse.com \
    --subject='Re: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).