guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#40927] [PATCH] Allow resume from swap device during boot


From: Tobias Geerinckx-Rice
Subject: [bug#40927] [PATCH] Allow resume from swap device during boot
Date: Fri, 01 May 2020 18:35:28 +0200

Jean-Baptiste,

Jean-Baptiste Note 写道:
This is a very important feature for people like me using GUIX SD on a
laptop (yes, it is possible, mine is a corebooted X230 running
linux-libre!)

Greetings, brother in hardware.

Note that hibernation and resumption already work fine if you rely on the kernel's built-in support. I've been hibernating my X230T for years without patches.

This explicit initramfs support is only needed if your storage drivers aren't available when the kernel itself tries to resume, and the initramfs has to retry later. That's slower but allows things like ahci to be modular instead of built-in.

This patch is based on a patch floating around. The core functionality has been isolated, the resume function isolated, the patch rebased and tested. I'm not taking credit for it, even though tracing the exact
origin is hard.

Heh. It's certainly very similar to a patch of mine that's ‘out there’ although it's probably not the only one.

The resume hook is called if the resume= kernel argument is provided,
which one can do during system configuration.

This patch ignores the ‘noresume’ flag, which is bad. If it's present anywhere on the command line resumption should be skipped:

+        (when (and (not (member "noresume" args))
+                   resume-device
+                   (file-exists? resume-device)
+                   (file-exists? "/sys/power/resume"))
+          (resume-from-device resume-device))

My scheme level is zero, so please bear with me. In particular, some
conditionals could maybe be moved within the function,

I'd like to see everything moved into a self-contained DTRT [try-to-]resume procedure, except for the ‘noresume’ check (so callers are free to explicitly resume if they so please):

+        (unless (member "noresume" args)
+ (resume-if-hibernated (find-long-option "resume" args)))

This is what the last iteration of my patch does.

If (find-long-option "resume" args) is #f, fall back to CONFIG_PM_STD_PARTITION. This is what the kernel does: even if ‘resume=’ is missing, it will try to resume from that device if specified. We should match that behaviour if we can.

Problem is, I forgot how to get that value from user space, or if it's even possible. I gave up on Linux's built-in hibernation (swsusp) years ago. It's poorly written and maintained, and the author fiercely defends it from all improvement.

Instead I use TuxOnIce, which exposes it under /sys/power/tuxonice/…. That's obviously not an option here, although it would be friendly to fall back to it for us ToI users :-)

*user.

I think ToI even exposes the ‘last used hibernation device’ somewhere, so user space can just use that instead of CONFIG_PM_STD_PARTITION. This is obviously the right thing to do. Again, not sure if swsusp does.

or the function itself called within some already-available hooks.

We don't have a concept of ‘initramfs hooks’ and I think that's a good thing. Gives me dracut flashbacks. Don't lets bother with them until we need them, which is never.

Also it is not clear if the commit log is adequate for such a change.

It's all right :-)  If anything, it's too long:

 linux-boot: Add support for resuming from swap device.

 * gnu/build/linux-boot.scm (resume-from-device): New procedure.
* gnu/build/linux-boot.scm (boot-system): Call it, unless ‘noresume’
   is present on the kernel command line.

Please let me know how to improve this and get this merged; I can also write some documentation (probably once the mechanism is in place) to
explain how the feature can be used.

If this works properly no documentation is needed. The kernel by default writes to the first swap device; we should magically resume from it. Forcing users to know (or care) about part 2 is asymmetrical and wrong.

Not sure if that's possible with vanilla Linux-Libre…

Will stop shilling ToI for now,

T G-R

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]