From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id HHv2HzhQ9l+bQgAA0tVLHw (envelope-from ) for ; Thu, 07 Jan 2021 00:05:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GCZRGzhQ9l+GDgAA1q6Kng (envelope-from ) for ; Thu, 07 Jan 2021 00:05:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D519494050C for ; Thu, 7 Jan 2021 00:05:11 +0000 (UTC) Received: from localhost ([::1]:38642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxIne-0007Pw-M8 for larch@yhetil.org; Wed, 06 Jan 2021 19:05:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxInW-0007Pi-HB for guix-patches@gnu.org; Wed, 06 Jan 2021 19:05:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:34370) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kxInW-0004wY-9x for guix-patches@gnu.org; Wed, 06 Jan 2021 19:05:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kxInW-0007qP-4B for guix-patches@gnu.org; Wed, 06 Jan 2021 19:05:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#45703] kernel-module-configuration-service for configuring kernel parameters Resent-From: raid5atemyhomework Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 07 Jan 2021 00:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45703 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Danny Milosavljevic X-Debbugs-Original-Cc: "ludo@gnu.org" , raid5atemyhomework via Guix-patches via , "45692@debbugs.gnu.org" <45692@debbugs.gnu.org> Received: via spool by submit@debbugs.gnu.org id=B.160997785630095 (code B ref -1); Thu, 07 Jan 2021 00:05:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Jan 2021 00:04:16 +0000 Received: from localhost ([127.0.0.1]:45916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxIml-0007pL-KF for submit@debbugs.gnu.org; Wed, 06 Jan 2021 19:04:15 -0500 Received: from lists.gnu.org ([209.51.188.17]:32792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxImk-0007pE-BS for submit@debbugs.gnu.org; Wed, 06 Jan 2021 19:04:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxImj-0007NT-1J for guix-patches@gnu.org; Wed, 06 Jan 2021 19:04:14 -0500 Received: from mail-40135.protonmail.ch ([185.70.40.135]:47327) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxIme-0004eO-1G for guix-patches@gnu.org; Wed, 06 Jan 2021 19:04:12 -0500 Date: Thu, 07 Jan 2021 00:04:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1609977844; bh=d3Ry/xjDaP+dE6gE2ujwfTaJHs3PWHZ1uPkKd4mERVY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=movietufHyBuzlxm4+HNuyzY07Jp8L1HSwhvFyHXR6tDIX58we/ica2El8hg0Oe8o yh6EiwnKBdBCUk0WSewdsHp7vN/Tgv8HvEqRxYG0dHmyUP33cyxQKAyXbT4H9ktTV7 7OJkgTlWw0KYS+gNcCRO5M2eTKxJWwZdpfrgY0tE= Message-ID: In-Reply-To: <20210106204134.38e83db4@scratchpost.org> References: <6wemXB-PfHUqbuVr5-XRf0-tY4cKGGtKiUqrZPrIZYXoBw17L3xRuZrGOJQfTo5PKfFNCM8KyRTllidoc7asPE2x98BTiJSPVR7OSjxCuw8=@protonmail.com> <20210106204134.38e83db4@scratchpost.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.135; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-40135.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 45703@debbugs.gnu.org, 45692@debbugs.gnu.org Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" Reply-to: raid5atemyhomework , raid5atemyhomework via Guix-patches From: raid5atemyhomework via Guix-patches via X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.84 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=protonmail.com header.s=protonmail header.b=movietuf; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: D519494050C X-Spam-Score: -2.84 X-Migadu-Scanner: scn0.migadu.com X-TUID: mjPrc1qmhq8D Hello Danny, > See also https://issues.guix.info/issue/42193 for an earlier attempt (whi= ch > is already very far--but it has a bug somewhere). There's also already a > kernel profile thing like you wrote in that patchset. > (Note that I would prefer there not to be a "LOAD?" in there because it > confuses loading the module (which is usually NOT started by user space > but by the kernel on its own) and confguring the module (which has to be > done by user space because it's specifying policy, not mechanism)) Looks like that patchset was merged in, so basically I can just depend on t= hat? So the first patch in this patchset would be dropped? > But I guess the ZFS Linux kernel module can't be built-in into the kernel > anyway. > > But that's a special case--in general, it's very much possible to make mo= dules > built-in. ZFS *can* be built-in to the kernel, Ubuntu does it. You can't distribute i= t like that (Ubuntu distributes it like that but presumably they have enoug= h lawyers to muddy the waters so that they can get away with it), but as th= e documentation in this patch notes: the user has every right to do whateve= r they want on the machine they own, including build a Linux kernel that ha= s ZFS built-in and run it, they just can't make that version available to s= omebody else. So to go whole-hog, we would have a service that replaces the kernel packag= e and inserts kernel module sources in-tree somehow, then compiles Linux-li= bre on the user's machine. That would probably be a lot more painful to ins= tall ZFS with (the user has to recompile the whole kernel at each update of= either kernel or ZFS, whereas with a kernel module the user has to recompi= le just the kernel module), so maybe kernel module is still better overall. > > - ;; You'd think we could've used kernel-module-l= oader-service-type, > > > > > > Definitely. > > > - ;; but the kernel-module-loader shepherd servic= e is dependent on > > > > > > - ;; file-systems, > > > > > > Yes--but why is that dependent on 'file-systems ? Is it because it needs = /proc ? > Or is it an oversight ? I would prefer to get rid of this dependency and = then > use kernel-module-loader-service-type. Dunno --- one VM I tested, I removed the `zfs-scan-automount` shepherd serv= ice from the `file-systems` target, and the VM still wouldn't boot, claimin= g a stack overflow (the same error which I got when I was still trying to u= se kernel-module-loader-service-type here). Or maybe I just got confused w= ith which VM was which, testing VMs wasn't a stress-free vacation. I just = want ZFS, because MD RAID5 ate my homework, this is getting tiresome... One thing I notice about `kernel-module-loader-service-type` is that it's n= ot instantiated in essential services, or indeed anywhere in Guix. A few s= ervices *do* extend it. But my **very rough** understanding is that if you= 're going to extend a service, it had better be instantiated *once* in the = list of services. In particular I note that the documentation for `kernel-module-loader-servi= ce-type` shows an example where it uses `service` to program the `kernel-mo= dule-loader-service-type`, not `simple-service`. This suggests to me that = `kernel-module-loader-service-type` is broken because it's not in the list = of essential services but is extensible. Maybe. It's designed as an exten= sible service, but isn't instantiated at default. Maybe that's what really= bit me and not the shepherd circular dependency loop? *shrug* > > Also, this manual loading of kernel modules is not supposed to be the way= to > do things in Linux. That a kernel module was compiled as a module is > an implementation detail--so Linux should (and usually does) automaticall= y > load kernel modules the first time a device for them is accessed (after a= ll, > how would user space know whether something is compiled as a module or > built-in--that would be too much to ask). So how do I get ZFS loaded? Note that the devices it targets are block devi= ces and it needs to scan for block devices that are formatted for ZFS. Do = other filesystems have some autoload rule? Thanks raid5atemyhomework