From: Jessica Yu <firstname.lastname@example.org> To: Heiner Kallweit <email@example.com> Cc: Lucas De Marchi <firstname.lastname@example.org>, Petr Mladek <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, email@example.com, "firstname.lastname@example.org" <email@example.com>, firstname.lastname@example.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: <email@example.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
prev parent reply other threads:[~2020-04-15 9:16 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).