From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:52814) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK0L9-00037W-Hu for guix-patches@gnu.org; Thu, 02 Apr 2020 09:57:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK0L8-0005i1-9j for guix-patches@gnu.org; Thu, 02 Apr 2020 09:57:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:56988) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jK0L8-0005hd-6d for guix-patches@gnu.org; Thu, 02 Apr 2020 09:57:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jK0L8-0005u3-3U for guix-patches@gnu.org; Thu, 02 Apr 2020 09:57:02 -0400 Subject: [bug#40274] [PATCH v5] gnu: Add kernel-module-loader-service. Resent-Message-ID: Date: Thu, 2 Apr 2020 15:56:40 +0200 From: Danny Milosavljevic Message-ID: <20200402155640.121e4879@scratchpost.org> In-Reply-To: <20200402123712.338-1-brice@waegenei.re> References: <20200328135908.2540-1-brice@waegenei.re> <20200402123712.338-1-brice@waegenei.re> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/31tP6Te17+=uVqQ1L440PeC"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Brice Waegeneire Cc: ludo@gnu.org, 40274@debbugs.gnu.org --Sig_/31tP6Te17+=uVqQ1L440PeC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Brice, I wonder how common it is to pass arguments to the modules explicitly in no= rmal operation. I haven't done it often even in other distributions--and I'm a kernel hacke= r. See also https://linux.die.net/man/5/modprobe.d for an alternative. I'm not necessarily against doing it like you do it, but just want to bring= up the possibility of just omitting the functionality and let it be someone-else's-problem, possibly another guix service that prepares /etc/modprobe.d with module options and other things (aliases, installation= and removal invocations). That's also important because Linux tries to (lazy-)autoload modules whenev= er possible (via invoking modprobe). In that case, the argument handling would be inconsistent between if it was lazy-autoloaded compared to if it was loa= ded by your loader. (I even wonder if it were better for kernel-module-loader-service to read t= he modprobe to use from /proc/sys/kernel/modprobe in order to make the situati= ons a little more consistent) For example let's say the following happened: (1) Linux boots up. (2) Someone accesses some device so "modprobe foo" is invoked by Linux. (3) foo is loaded, gets options from /etc/modprobe.d (usually none). [Time passes, other stuff happens] (4) Your kernel-module-loader-service is started, invokes "modprobe foo x= =3D2". (5) x=3D2 is not passed to the Linux kernel module ever. I'm just saying maybe not invite this kind of trouble in the first place. I don't think it fits Guix's declarative configuration style to do that either. Also, when reconfiguring the Guix system, kernel-module-loader-service won't unload the kernel modules and thus also wouldn't load it with new options. Also, it could happen that two different guix services require the same mod= ule but with different options. That's an insane problem to have and I wouldn't try to support it. (I've reviewed your patch, otherwise OK!) --Sig_/31tP6Te17+=uVqQ1L440PeC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl6F7xgACgkQ5xo1VCww uqVSlAf/cXcL9VlmptSSYEBlNbKXibrRYJdMtw07amj16IrYtnX5oiLcqEm/jkWF N6Vl/uu1PZn/592Ifx2+2Dc7bJ3NMP1S7hvFy9b5/cQIz5nGxmf+CgDbHGdIKt76 wl4pfmGGzTE7qVdU9x+BBUFkU1Aq1qv0wMbAUJFqXecueKYb15SnH7+5aHCklBIn wqtQAq01NKzgPz0iONAohl0WXAlws9D+Ru+Kugo94Pt5Lzp8K+hecx7UPpWoh9pd 71GWgybbYIEvjlm5AijdbykGXL/wkJi7Y6VpbesfgH7fMpZGThUFqoW5z6Ej7lwl MZnb3knRZSgmeHt3P40zEN422HIIPQ== =R/Dn -----END PGP SIGNATURE----- --Sig_/31tP6Te17+=uVqQ1L440PeC--