From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:44322) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK3Pn-00063N-Mh for guix-patches@gnu.org; Thu, 02 Apr 2020 13:14:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK3Pm-0003Jm-5p for guix-patches@gnu.org; Thu, 02 Apr 2020 13:14:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57373) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jK3Pm-0003Je-1c for guix-patches@gnu.org; Thu, 02 Apr 2020 13:14:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jK3Pl-00047Q-Sz for guix-patches@gnu.org; Thu, 02 Apr 2020 13:14:01 -0400 Subject: [bug#40274] [PATCH v5] gnu: Add kernel-module-loader-service. Resent-Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 02 Apr 2020 17:13:05 +0000 From: Brice Waegeneire In-Reply-To: <20200402155640.121e4879@scratchpost.org> References: <20200328135908.2540-1-brice@waegenei.re> <20200402123712.338-1-brice@waegenei.re> <20200402155640.121e4879@scratchpost.org> Message-ID: <2b32956fc10fd3012388722e1b00ce21@waegenei.re> 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: Danny Milosavljevic Cc: ludo@gnu.org, 40274@debbugs.gnu.org On 2020-04-02 13:56, Danny Milosavljevic wrote: > Hi Brice, > > I wonder how common it is to pass arguments to the modules explicitly > in normal > operation. > > I haven't done it often even in other distributions--and I'm a kernel > hacker. > > 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 > whenever > possible (via invoking modprobe). In that case, the argument handling > would > be inconsistent between if it was lazy-autoloaded compared to if it was > loaded > by your loader. > > (I even wonder if it were better for kernel-module-loader-service to > read the > modprobe to use from /proc/sys/kernel/modprobe in order to make the > situations > 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=2". > (5) x=2 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 > module > 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!) Hello Danny, Thank for taking the time to review this patch. Since I'm definitely *not* a kernel hacker --just a casual user-- I wasn't aware of the uselessness of specifying the module arguments to modprobe in such service. I wrote this patch just to load this pesky non auto-loading `ddcci-backlight` module and I have no current use of specifying module arguments. I just thought it *could* be useful, to some, to pass arguments to modprobe since it is present in its API; but the edge-cases you brought up show that it wasn't a good idea after all. Should I just go back to the first format, with just a list of module names, and we merge this patch? Or would it be better, regarding the user interface, to start this patch anew by using `modprobe.d` API as a base. By that I mean defining a `modprobe-service-type` which populates `/etc/modprobe.d/` and can manually load a module at boot if needed (like kernel-module-loader does)? Would it be overkill? Following is an example of what such service could look like: #+begin_src scheme (service modprobe-service-type (list (modprobe-entry (module "ddcci") (load? #t) (options '("dyndbg" "delay=120")) (alises '("ddc/ci")) (install "") ; default (remove "")) ; default (modprobe-entry (module "acpi-call") (blacklist? #t)))) #+end_src - Brice