From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#34902: guix cannot find a module on boot Date: Mon, 18 Mar 2019 23:40:28 +0100 Message-ID: <20190318231359.217af9f4@scratchpost.org> References: <813466538d530a38bddf60ed348cb75b@lepiller.eu> <87o967lxsa.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/We2RqDTikCVCheNw4kqNjuQ"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:55746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h60wM-0007HA-W3 for bug-guix@gnu.org; Mon, 18 Mar 2019 18:41:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h60wL-00084x-NC for bug-guix@gnu.org; Mon, 18 Mar 2019 18:41:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35784) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h60wI-00081c-KN for bug-guix@gnu.org; Mon, 18 Mar 2019 18:41:05 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h60wI-00004z-E1 for bug-guix@gnu.org; Mon, 18 Mar 2019 18:41:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87o967lxsa.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 34902@debbugs.gnu.org --Sig_/We2RqDTikCVCheNw4kqNjuQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > This underscore vs. hyphen thing is terrible. Yeah. But looking at kmod, it doesn't seem to be so bad for them. They basically always use the version with underscores as the lookup key for their internal hash tables. For alias resolving, they use a resolver for [a-zxxx] AND they replace dashes THAT ARE NOT IN THE "[...]" block by underscore before using it for lookups. modules.dep entries are always file names (no replacements whatsoever). When a module is loaded as a result of an alias lookup, it has a special key (string-append name "\" target-alias). No idea what that's for. I'd caution about complicating our version overly much by putting just-in-case replacements everywhere. Rather we should find out what their original strategy is (if any :P) and do that as well. Module aliases (the alias itself, not what it's resolved to) sometimes look like that: ./arch/x86/crypto/des3_ede_glue.c:MODULE_ALIAS_CRYPTO("des3_ede-asm"); WTF... But the thing the alias is resolved to is always the modname (which has hyphens replaced by underscore and stops before a dot). Their bin files (we don't use them) always have the final modname as key, as opposed to their source files (for example "modules.alias" rather than "modules.alias.bin"). (The source files sometimes have paths as key) I think that they assume that each module, whether it has dependencies or not, is listed in modules.dep . They use modules.dep.bin for the lookup of a module by modname, rather than by path. So I think a pretty good fix is: Every time we want to lookup a module by modname, check a hashtable that is built from modules.dep by: =20 * let x-path be the first value of each modules.dep line. * Then the key for the hashtable entry is (underscore (stop-at-dot (basenam= e x-path))) * And the value for the hashtable entry is x-path. In this way we would look up modules in a way similar to them. Why they couldn't just have used file names without mangling them beats me. Sigh... --Sig_/We2RqDTikCVCheNw4kqNjuQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlyQHlwACgkQ5xo1VCww uqWbnwgAky0WPwHawV/qHLAND/5I8OvGn1CSwkjCsZS8wrHtOO6hOhfJiymOZqZs CJeK+wUK9dS+nCa46ee8xeHF2XObl/jtlbkNewtCBjUPAtj/MzINlYcG3UvntKyc Yvs4ZICC6nk0yAy3rHeeuBrenRoHDT69HTi175in+YikNwZ1mgrXk5dkgkmFPI1f kDCYFW23r1XNywIvQUauXw4Kx2yob/ku2hNyzRXjOt6ietnUCpiuyz+mY8CKYGpF CRcmOEFz5/OSnSUrfRUZddW5N7pl/o9mUM6Km9eId55b8RWxjXGFtlSMkMJf5s2A LdB3E6eSKt0zWS0fyOzUS9nhCxQAdw== =c5jZ -----END PGP SIGNATURE----- --Sig_/We2RqDTikCVCheNw4kqNjuQ--