archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <>
To: Heiner Kallweit <>
Cc: Lucas De Marchi <>,
	Petr Mladek <>,
	Linux Kernel Mailing List <>,,
	"" <>,
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: <>

+++ 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:
>>> 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.


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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-04-01 21:22 ` Fwd: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek) 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:

* 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 \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).