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