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