From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 23:55:00 2021 Received: (at submit) by debbugs.gnu.org; 24 Oct 2021 03:55:00 +0000 Received: from localhost ([127.0.0.1]:37678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meUb5-0005eL-M1 for submit@debbugs.gnu.org; Sat, 23 Oct 2021 23:55:00 -0400 Received: from lists.gnu.org ([209.51.188.17]:38802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meUb2-0005e4-VW for submit@debbugs.gnu.org; Sat, 23 Oct 2021 23:54:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meUb2-0006R1-Jx for guix-patches@gnu.org; Sat, 23 Oct 2021 23:54:56 -0400 Received: from tobias.gr ([2a02:c205:2020:6054::1]:34116) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meUaz-0005TA-Jv for guix-patches@gnu.org; Sat, 23 Oct 2021 23:54:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=2018; bh=i17HGVfzDSfHC ztu+Mk9oi6MXQ7cIqnx0o68biTgwBQ=; h=in-reply-to:date:subject:cc:to: from:references; d=tobias.gr; b=ffu3x1vLDpGVjylqc4DQXrb0jaaDOOiWlTrWdx ircf5crM19lhC0/i0WHaFhQTm6VtYbKevCLgT2zDaSxe7ENs6TGwwARkYTbM3cCGNb67zW PopjLoyQcF4pbRJy9SlTTPKy0URkIpIpib5kb2stw6Fv1m2AFrmXLroVo0vtCQQyjzIroj GT0VoTnU4DsXiGUQ4iAPAVTjhUpc/Lr1Y7UQYkrC+zikBan1rqnu4as0+Z8/tChvEy0cOF lzLj0nyv0BpoBrXl/jdXsXP6KzHfpO1lDHL/VQterTOvVkbiIHz8CnR5oV8C2xIthYNOlJ fqDsNq8JfLeJOImIOUg13Mrg== Received: by submission.tobias.gr (OpenSMTPD) with ESMTPSA id 6e0234f3 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sun, 24 Oct 2021 03:54:45 +0000 (UTC) References: <87fsssdqg2.fsf@jpoiret.xyz> From: Tobias Geerinckx-Rice To: Josselin Poiret Subject: Re: [bug#51346] [PATCH 0/1 core-updates-frozen] Rework swap device to add dependencies and flags Date: Sun, 24 Oct 2021 04:05:30 +0200 In-reply-to: <87fsssdqg2.fsf@jpoiret.xyz> BIMI-Selector: v=BIMI1; s=default; Message-ID: <8735orjcvb.fsf@nckx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a02:c205:2020:6054::1; envelope-from=me@tobias.gr; helo=tobias.gr 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: 51346@debbugs.gnu.org, guix-patches@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Josselin, Josselin Poiret via Guix-patches via =E5=86=99=E9=81=93=EF=BC=9A > This patchset adds new record types swap-partition and=20 > swap-file, to be used in the swap-devices field of=20 > operating-system. Thank you so much for this. Do you happen to know anything about how the Hurd handles swap? > in the manual I refer to 'man 2 swapon' for the description of=20 > these flags. I think we should document the basics ourselves. We can still=20 refer to the man page if you think it's needed. WDYT? Pity that there's no (libc) Info node to which we can link. > This works well on my laptop, whereas my swap file used to never=20 > be swapon on boot because it wasn't available yet (on BTRFS on=20 > LUKS). I don't have a swap partition lying around though so=20 > testers welcome! Also boots fine with my plain swap partition: (swap-devices (list (swap-partition (device hibernation-device)))) Not having to explicitly manage HIBERNATION-DEVICE, as you suggest=20 below, sounds nice too :-) > I hope this can make it in time for the core-updates-frozen=20 > merge. As noted on IRC, I don't see a reason to involve core-updates at=20 all. We should take the time to define solid interfaces but, once done,=20 this can go straight to master. > I also plan to add swap file hibernation support eventually,=20 > where the file offsets are automatically determined by guix (or=20 > we could even write our own suspend/resume script in guile, see=20 > https://www.kernel.org/doc/html/latest/power/userland-swsusp.html). Okay. As also implied on IRC=E2=80=A6 I have a very low opinion of=20 uswsusp. It's brittle, gimmicky, and introduces many ways for=20 bugs to hide and boots to break. We'll have to carefully track=20 incompatible format changes and kernel/initrd generations. If it is added, we shouldn't involve early userspace in cases=20 where it's not strictly needed. But that for later :-) > +++ b/doc/guix.texi > +* Swap Space:: Adding swap space. You're following existing precedent here, but I just read the same=20 thing twice. I suggest =E2=80=98Swap Space:: Adding virtual memory to free up precious=20 RAM.=E2=80=99. > +@cindex swap devices > +A list of @code{} or @code{} objects > +(@pxref{Swap Space}), to be used for ``swap space''=20 > (@pxref{Memory > +Concepts,,, libc, The GNU C Library Reference Manual}). At the risk of leaving this very stubby, I think the (libc) ref=20 should be moved to the Swap Space node, which readers might visit=20 directly without reading the above. > +@node Swap Space > +@section Swap Space > +@cindex swap space =E2=80=A6so, here. I'm missing a short intro sentence that mentions what swap is for,=20 and that it comes in 2 common forms. The libc explanation is quite technical, doesn't actually define=20 =E2=80=98swap space=E2=80=99 except by implication, and immediately rambles= on=20 about zeroes that don't even exist. As a new user, I think I'd=20 feel lost. > +@deftp {Data Type} swap-partition > +Objects of this type represent swap partitions. They contain=20 > the following > +members: (What are =E2=80=98swap partitions=E2=80=99? Maybe explain the pros/cons o= f both=20 in each @deftp intro. Mostly a reminder to myself, but if you=20 want to write more docs: be my guest.) Always double-space after full stops in prose. > +@item @code{flags} (default: @code{'()}) > +A list of flags. The supported flags are @code{'delayed} and > +@code{('priority n)}, see @command{man 2 swapon} in the kernel=20 > man pages > +(@code{man-pages} guix package) for more information. 'delayed? To? When? I'm unenthusiastic about this interface. On the one hand, exposing this tiny and ossified list of 2.5=20 =E2=80=98flags=E2=80=99 (what even is that priority=E2=80=A6 thing=E2=80=A6= ) this way feels like=20 exposing users to an ugly C implementation detail for no benefit:=20 why not (swap-partition (priority 5) ; or #f distinct from 0 (discard? #t) =E2=80=A6) instead? On the other hand: perhaps other kernels expose different flags=20 and this model might make sense. I'm not convinced, but I'm=20 willing to be. > +A string, specifying the file path of the swap file to use. s/file path/name/ > +@item @code{fs} s/fs/file-system/ As a rule, avoid such pointless abbreviation. GNU's not unix,=20 thankfully. That said, why does this field exist at all? The example given=20 here: > +@item (swap-file (path "/swapfile") (fs root-fs)) > +Use the file @file{/swapfile} as swap space, which is present=20 > on the > +@var{root-fs} filesystem. =E2=80=A6rather side-steps the question of how this is supposed to work,=20 or in which situation it makes sense. I feel like it's papering=20 over a bug. > +(define (swap-flags->bit-mask flags) So I made the mistake of looking at how util-linux does this. Firstly, it silently clamps (> priority max) to MAX. I think it=20 makes sense to follow that behaviour, but print a warning.=20 Ignoring (< priority 0), with a warning, is fine. Secondly, and this is just weird, =E2=80=98man 2 swapon=E2=80=99 explicitly= =20 documents: (prio << SWAP_FLAG_PRIO_SHIFT) & SWAP_FLAG_PRIO_MASK so naturally util-linux's swapon.c explicitly does this: (prio & SWAP_FLAG_PRIO_MASK) << SWAP_FLAG_PRIO_SHIFT What? Surely this ancient code can't work just by sheer luck=E2=80=A6=20 I'll ask. I see no advantage in ignoring SWAP_FLAG_PRIO_SHIFT, only risks.=20 Let's not. Here's how I'd write it: =2D-8<---------------cut here---------------start------------->8--- (define (swap-flags->bit-mask flags) "Return the number suitable for the 'flags' argument of 'mount'=20 that corresponds to the symbols listed in FLAGS." (let loop ((flags flags)) (match flags ((('priority p) rest ...) (if (< p 0) (begin (warning (G_ "Ignoring swap priority ~a as it is less=20 than 0.~%" p)) (loop rest)) (let* ((max (ash SWAP_FLAG_PRIO_MASK (-=20 SWAP_FLAG_PRIO_SHIFT))) (pri (if (> p max) (begin (warning (G_ "Limiting swap priority ~a to ~a.~%" p max)) max) p))) (logior SWAP_FLAG_PREFER (ash pri SWAP_FLAG_PRIO_SHIFT) (loop rest))))) (('discard rest ...) (logior SWAP_FLAG_DISCARD (loop rest))) (() 0)))) =2D-8<---------------cut here---------------end--------------->8--- It should also handle invalid input by printing the offending=20 symbol instead of a generic match error, but I'm about to board my=20 train, and will call it a night here. Kind regards, T G-R --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYXTZGA0cbWVAdG9iaWFz LmdyAAoJEA2w/4hPVW15ZJcBAOhKTgpWIQz+TuEb0nLqlgFCNyGFWZ2M99MZKE9M 48OFAP9cBOJZsPcOuKYT1HRA8UoQZH66XYfoevEl+CDoh8cVAQ== =Di8U -----END PGP SIGNATURE----- --=-=-=--