From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WGDjNnAD9F/AEAAA0tVLHw (envelope-from ) for ; Tue, 05 Jan 2021 06:13:04 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id YcqZMnAD9F8DFQAAbx9fmQ (envelope-from ) for ; Tue, 05 Jan 2021 06:13:04 +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 6E5B394011C for ; Tue, 5 Jan 2021 06:13:04 +0000 (UTC) Received: from localhost ([::1]:47996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwfaZ-0007Jc-62 for larch@yhetil.org; Tue, 05 Jan 2021 01:13:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwfaG-0007JP-Kb for guix-devel@gnu.org; Tue, 05 Jan 2021 01:12:44 -0500 Received: from zancanaro.com.au ([45.76.117.151]:48534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwfaC-0001fk-Gr for guix-devel@gnu.org; Tue, 05 Jan 2021 01:12:44 -0500 Received: by zancanaro.com.au (Postfix, from userid 116) id CEC1521535; Tue, 5 Jan 2021 06:12:33 +0000 (UTC) Received: from jolteon (unknown [27.96.215.68]) by zancanaro.com.au (Postfix) with ESMTPSA id 80E0D21520; Tue, 5 Jan 2021 06:12:32 +0000 (UTC) References: <87b59430-b53e-47ec-32d5-abbd3be42ce7@gmail.com> User-agent: mu4e 1.4.13; emacs 27.1 From: Carlo Zancanaro To: raid5atemyhomework Subject: Re: A new paradigm for modifying operating system declarations In-reply-to: Date: Tue, 05 Jan 2021 17:12:31 +1100 Message-ID: <87o8i39ak0.fsf@zancanaro.id.au> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=45.76.117.151; envelope-from=carlo@zancanaro.id.au; helo=zancanaro.com.au X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.34 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 6E5B394011C X-Spam-Score: -2.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: PbdSBQkqOuLr Hi raid5atemyhomework, On Tue, Jan 05 2021, raid5atemyhomework wrote: > What `install-zfs` does is that it installs the same > kernel-specific package in three different points: > > * `kernel-loadable-modules`, because ZFS needs to get into the > kernel somehow. > * `packages`, because the kernel module is useless if you don't > have the userland tools to interact with the kernel module. > * `services`, because ZFS is well-documented outside of Guix as > automatically mounting its filesystems at bootup, but that > actually requires a bit of magic in the `init` system, > specifically you need to actually **load** the module, then > execute `zpool import -a -l` to have it scan for all filesystems > and mount those that need automounting. > > Thus, an `install-zfs`, that is a *single* form that inserts the > correct bits in the correct ***three*** places, makes the > experience of adding ZFS to your `operating-system` easier > because there's less scope for error in actually adding the > package. You just add a single `install-zfs`, not add three > things (plus an extra `(define my-zfs (make-zfs-package > linux-libre-5.4))` before your form). In principle, I think this should all be handled by a service. Services have a number of extension points where they can impact the operating system being declared, by extending other services. For example, adding a package into the global profile is done by extending profile-service-type (which you can find in gnu/services.scm). Adding a shepherd service to manage a process is done by extending shepherd-root-service-type (in gnu/services/shepherd.scm). This is how many services work. As an example, sddm-service-type extends services to: (a) start a process on the running system, (b) put files in /etc, (c) install some pam services, (d) add an account on the system, and (e) install packages in the global profile. As far as I can tell, the only thing missing for a zfs-service-type to do what you want is that services can't currently add new kernel modules (although they can load them via kernel-module-loader-service-type). I may have missed a mechanism for this, though. If we added the ability to do this, then it should be possible to add zfs support by adding a single (service zfs-service-type) to your services list. The approach of using services in this way has some advantages which are outlined in a blog post from 2015[1]. For me the most compelling advantage is that an zfs-service-type is more restricted in what it can do, and must be more explicit. An install-zfs procedure has free-reign over the entire operating-system definition that it gets passed, which makes it harder to reason about the composition of such procedures. Carlo [1]: https://guix.gnu.org/blog/2015/service-composition-in-guixsd/