basic resume support #49
Conversation
| } | ||
|
|
||
| return nil | ||
| resume: |
There was a problem hiding this comment.
i dont love this but if there's a larger refactor in the cards I'll address whether or not a goto makes sense here later
There was a problem hiding this comment.
Yeah, this device matching logic needs to be simplified and made consistent. I want to review/refactor it in the short term.
Either adding the goto here (and I'll change it later) or wait for the refactoring works for me.
| } | ||
|
|
||
| return nil | ||
| resume: |
There was a problem hiding this comment.
Yeah, this device matching logic needs to be simplified and made consistent. I want to review/refactor it in the short term.
Either adding the goto here (and I'll change it later) or wait for the refactoring works for me.
| return false | ||
| } | ||
|
|
||
| func resume(devpath string) error { |
There was a problem hiding this comment.
does this patch handles suspend-on-disk only? is there anything special need to be to handle suspend-to-ram functionality?
There was a problem hiding this comment.
This is purely for suspend-to-disk. Suspend-to-ram doesn't go through a reboot, so it's handled by the running kernel.
|
|
||
| rd := fmt.Sprintf("%d:%d", major, minor) | ||
| debug("resume matched: %s=%s, writing %s", resume, resumeDevice, rd) | ||
| if err := os.WriteFile("/sys/power/resume", []byte(rd), 0644); err != nil { |
There was a problem hiding this comment.
where I can find more information about this "echo $diskno > /sys/power/resume" operation. What exactly kernel does here? How does suspend-to-XXX implemented in Linux?
There was a problem hiding this comment.
A couple resources:
-
https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Required_kernel_parameters has a summary of what's going on here
-
From the kernel docs:
resume= [SWSUSP] Specify the partition device for software suspend Format: {/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>} resume_offset= [SWSUSP] Specify the offset from the beginning of the partition given by "resume=" at which the swap header is located, in <PAGE_SIZE> units (needed only for swap files). See Documentation/power/swsusp-and-swap-files.rst -
for reference, mkinitcpio has similar logic, as does dracut
One thing that I noticed when implementing this is that it appears that we don't need to handle the resume_offset kernel parameter in the initrd, just the resume parameter - the kernel seems to parse that from its commandline itself when resuming, but it needs /sys/power/resume to have the major/minor of the block device set already for the resume to occur. Neither dracut nor mkinitcpio handle the resume_offset parameter either.
| return false | ||
| } | ||
|
|
||
| func resume(devpath string) error { |
There was a problem hiding this comment.
Is there anything need to be done by booster at suspend time? Or it is assumed that the host software (e.g. systemd) handles it without involving booster.
There was a problem hiding this comment.
nope, as long as /sys/power/resume and /sys/power/resume_offset are set correctly, when suspend-to-disk happens the kernel handles everything
If user can specified 'resume' boot flag and it matches a block device then booster resumes this device using '/sys/power/resume' sys interface. Closes #49
|
Thank you for your work. I just finished the I rebased your change on top of it and pushed both your changes and my refactoring to |
|
Also it would be really great to have an integration test for resume functionality. Is there a way to create a disk with "suspended" state and then boot using it? |
If user can specified 'resume' boot flag and it matches a block device then booster resumes this device using '/sys/power/resume' sys interface. Closes #49
|
D'oh messed up with git commit author. I am going to fix it really quick. |
If user can specified 'resume' boot flag and it matches a block device then booster resumes this device using '/sys/power/resume' sysfs interface. Closes #49
If user can specified 'resume' boot flag and it matches a block device then booster resumes this device using '/sys/power/resume' sysfs interface. Closes #49
|
Hi Ed, I would like to move with this change forward. Had you chance to review/verify the rebased commit? |
|
@anatol Hey, sorry, I've been dealing with some life stuff over the past week or so. I haven't forgotten about this, I'll find some time to rebase and test. |
|
No worries, you did a great work. Thank you very much for your contribution. |
This adds basic support for parsing the resume kernel parameter and setting
/sys/power/resumeappropriately. It works for me, but I haven't tested all combinations of argument formats yet (e.g. a LABEL device selector) -- I wanted to get this PR in front of people early because it kinda feels like a general refactor ofdevAddmight be in order if this approach I'm taking is what we want.Couple notes;
devAddhandler, because that's also where luks handling that similarly needs to lookup devices lives. I'm not sure if this is the best approach -- seems like we could maybe do the resume handling after we've mounted the root volume, and just no-op if the device hasn't been added by that point?devAddhandler makes sense, it's currently a bit unwieldy because there are a few return points from the function, and currently it seems like we'd have to call theresumehandler at each point. I'd love to discuss ways to refactor the function if necessary.