--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
I found a problem with the depmod from modutils-2.2.2-pre6.
Imagine you have modules from several kernel compilations or a set of
modules and several kernels with different options.
(And, before I hear you screaming that I should not do that and everything
will be risky then, anyway, let me tell you that this is unavoidable for s=
b.
making distributions. But it had probably also happended to you before, as
you don't do rm -rf before make modules_install, do you? And yes, root can
always shoot into his own foot, but we don't need to help him, do we?)
In this situation you call depmod to generate dependencies.
Now, a module needs some symbol, which is provided both in the running
kernel (which has the same version as modules) and in some other module.
Should the other module then be put as a dependency?=20
My answer is no. If all needed symbols are in the kernel, we should _not_
consider loading a module providing this symbol.
Sadly, depmod's answer is sometimes yes.
Consequently, modprobe will try to unnecessarily load modules. If you are
lucky, insmod will fail and the final module is just not loaded. Bad enough,
because it could easily loaded, if you would not try the other one before .=
..
But there are even worse cases:
sg depends on scsi_mod in spite of scsi support being in the kernel.
Loading of scsi_mod will succeed (!), but you loose access to your disks (!=
!)
(You can try this, but please sync before, so e2fsck has not too hard a work
to recover your fs. Don't blame me for your lost data!)
While you can work around by deleting all offending modules, I would prefer
depmod not to produce spurious dependencies. The solution is easily
achieved: If a symbol is found in kernel, prefer this one and don't
generate a dependency to another module providing it.
Probably a clean solution would be to change depmod to create two symbol
tables and first try the prefered, the kernel one and only look into the
module symbol table, if this fails.
However, I added a quick and dirty patch to depmod to prefer kernel modules:
In the routine to resolve symbols I changed it to go on looking for more
places until no more places are found or until a symbol in the kernel is
found. If the latter is true, this one is stored as dependency, otherwise
the first one found.
A patch for this is appended.
I'd suggest to apply this patch to depmod until sb. comes up with a better
solution. Let me add that it solved a couple if problems with some major
distro ;-)
Comments are welcome,
--=20
Kurt Garloff <garloff@suse.de> SuSE GmbH, N=FCrnberg, FRG
Linux kernel development; SCSI drivers: tmscsim(DC390), DC395
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="depmod.dif"
Content-Transfer-Encoding: quoted-printable
--- depmod/depmod.c.orig Thu Mar 25 13:16:37 1999
+++ depmod/depmod.c Thu Jul 22 14:58:11 1999
@@ -171,12 +171,17 @@
=20
for (find =3D symhash[psym->hashval]; find; find =3D find->next) {
if (strcmp(find->name, psym->name) =3D=3D 0) {
- psym->status =3D SYM_RESOLVED;
- psym->module =3D find->module;
- break;
+ /* garloff@suse.de, 99/07/22: */
+ /* Prefer kernel symbols! */
+ if (psym->status =3D=3D SYM_UNDEF || !strcmp(find->module->name,"-")=
) {
+ psym->status =3D SYM_RESOLVED;
+ psym->module =3D find->module;
+ /* break; */
+ if (!strcmp(find->module->name,"-")) break;
+ }
}
}
- if (!find)
+ if (psym->status =3D=3D SYM_UNDEF)
resolved =3D 0; /* still unresolved */
}
}
--TB36FDmn/VVEgNH/--
--oC1+HKm2/end4ao3
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
iQCVAwUBN6DHMBaQN/7O/JIVAQEm7wP/TjBbrn4jQL0JCvWGZitFYIwRKNpKoaUf
K10rFG5lKROrAj01nbjQjv/AFYmB58b8+j5aweZ0zK8tUMTqzweMWqBsnsSMqbsn
ektncINxNx/CHP9++yAy+TQtneNyUnItxu/2dUqRewBsnZtsA+wf55O13UR5MzDY
TGvxuab0p/w=
=0nAo
-----END PGP SIGNATURE-----
--oC1+HKm2/end4ao3--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/