Re: RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek)

[Jessica Yu]

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