[systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation

Umut Tezduyar Lindskog umut at tezduyar.com
Wed Aug 27 01:19:08 PDT 2014


Hi Ivan,

Great job!

I was wondering if a ./configure switch makes sense to disable it.
Embedded devices won't be using it.

Thanks

On Sat, Aug 23, 2014 at 2:47 PM, Ivan Shapovalov <intelfx100 at gmail.com> wrote:
> This patchset allows systemd to parse resume= kernel command line parameter
> and initiate resume from the specified device.
>
> It adds:
> - a 'systemd-resume' tool which takes path to a device node and
>   writes its major:minor to /sys/power/state;
> - a corresponding 'systemd-resume at .service' templated unit;
> - a 'systemd-resume-generator' generator which parses the kernel command line
>   and instantiates the unit as necessary.
>
> This functionality already exists in-kernel, but only for "/dev/sdXY"-style
> pathes. Implementing it in userspace allows to use arbitrary udev-created
> symlinks, e. g. persistent block device pathes ("/dev/disk/by-foo/bar").
>
> Userspace parsing of resume= kernel command line parameter has been
> traditionally done in initramfs via shell scripts (for Arch Linux, this is
> "resume" mkinitcpio hook), so I feel that this feature has its place within
> systemd.
>
> Due to the nature of hibernation, the resume unit must be activated before
> any modifications to filesystems take place. This can happen
> 1) in initramfs before mounting anything, and
> 2) without initramfs before remounting rootfs read-write (provided that it is
>    mounted RO initially).
>
> So, first patch orders all non-root fsck after local-fs-pre.target, which in
> turn allows to order the resume unit before those fsck instances.
>
> Second and third patches add the tool, the unit and the generator.
>
> There are some issues with this implementation:
>
> - legacy usr.mount is not automatically ordered after local-fs-pre.target,
>   so systemd-resume at .service has to be manually ordered before it;
> - systemd-udevd.service, which is needed for creating persistent block device
>   symlinks, is transitively ordered after systemd-remount-fs.service via at
>   least systemd-udev-hwdb-update.service and systemd-sysusers.service.
>   Hence, if these units are present (at least initramfs-less case), an ordering
>   cycle happens and resume is impossible.
>
> So, I would like someone to comment on these.
>
> This is my first patch to this project, so feel free to flak me for missing
> something obvious :)
>
> Thanks for reviewing!
>
> Ivan Shapovalov (3):
>   units: order systemd-fsck at .service after local-fs-pre.target.
>   resume: add a tool to write a device node's major:minor to /sys/power/resume.
>   resume-generator: add a generator for instantiating the resume unit.
>
>  Makefile-man.am                         |  9 ++++
>  Makefile.am                             | 28 ++++++++--
>  man/kernel-command-line.xml             | 13 ++++-
>  man/systemd-resume-generator.xml        | 91 +++++++++++++++++++++++++++++++++
>  man/systemd-resume at .service.xml         | 81 +++++++++++++++++++++++++++++
>  src/resume-generator/Makefile           |  1 +
>  src/resume-generator/resume-generator.c | 89 ++++++++++++++++++++++++++++++++
>  src/resume/Makefile                     |  1 +
>  src/resume/resume.c                     | 82 +++++++++++++++++++++++++++++
>  units/systemd-fsck at .service.in          |  2 +-
>  units/systemd-resume at .service.in        | 23 +++++++++
>  11 files changed, 414 insertions(+), 6 deletions(-)
>  create mode 100644 man/systemd-resume-generator.xml
>  create mode 100644 man/systemd-resume at .service.xml
>  create mode 120000 src/resume-generator/Makefile
>  create mode 100644 src/resume-generator/resume-generator.c
>  create mode 120000 src/resume/Makefile
>  create mode 100644 src/resume/resume.c
>  create mode 100644 units/systemd-resume at .service.in
>
> --
> 2.1.0
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


More information about the systemd-devel mailing list