From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brice Waegeneire Subject: Re: Issues and improvement for `kernel-loadable-modules' Date: Thu, 26 Mar 2020 15:22:46 +0000 Message-ID: <3137a0e02c3350c998da88b811bdc9c6@waegenei.re> References: <9c7f55a0dc9b1677b81a2cfd1e3dc840@waegenei.re> <20200326161342.2d469d54@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51888) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jHULM-0002cQ-Av for guix-devel@gnu.org; Thu, 26 Mar 2020 11:22:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jHULK-0003Fp-QO for guix-devel@gnu.org; Thu, 26 Mar 2020 11:22:51 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:43611) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jHULK-0003El-K0 for guix-devel@gnu.org; Thu, 26 Mar 2020 11:22:50 -0400 In-Reply-To: <20200326161342.2d469d54@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org On 2020-03-26 15:13, Danny Milosavljevic wrote: > Hi Brice, > > On Thu, 26 Mar 2020 14:34:03 +0000 > Brice Waegeneire wrote: > >> First I was expecting the packages in `kernel-loadable-modules' to use >> the >> `kernel' field as their kernel input or to have a simple procedure to >> do >> so. Otherwise you get a “Specified Linux kernel and Linux kernel >> modules >> are not all of the same version”. It makes it more difficult that it >> needs >> to be to write composable configurations; IOW why would I want to use >> a >> module built with a different kernel that the one I'm specifying in my >> `operating-system'. > > Because packages are modular, changing the build system can only be > done > retroactively by a procedure. We could totally do that but it would > make > the kernel-loadable-modules field more magical and more difficult to > debug. > Also, I guess it would hard-code linux-module-build-system for those > (right now you can use whatever build system you want). Do we want it > anyway? > >> And last issue, we are missing a service to load module manually when >> they >> can't be auto-loaded as it's the case with `ddcci`[1]. I have managed >> to >> solve this one by writing my first service >> `load-kernel-modules-service'. >> What can I improve before submitting it as a patch -- except the >> missing >> documentation? > > I think that things should be described by nouns and actions should be > described by verbs. > > So "load-kernel-modules-service" sounds really wrong to me. > Maybe "kernel-module-loader-service"? > > Others don't care so much because Scheme kinda erodes the boundary > anyway. > > Otherwise looks good to me. > > I guess it could be nice to be able to extend this service from other > services > using (service-extension load-kernel-modules-service-type '("module1" > "module2")) or something.