On Wed, Aug 27, 2014 at 02:05:41AM +0400, Ivan Shapovalov wrote:
On Tuesday 26 August 2014 at 17:42:54, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook.
Thanks so much for pushing this work upstream!
I'm confused a bit.
Apparently, I am too. My brain is largely fried from being sick for a week (and then traveling/partying copiously this past weekend). Let's try this again -- this time with a bit more context/detail.
Do you say that the 'systemd' hook currently in core/systemd shall be eventually moved to core/mkinitcpio?
Actually, no. I'm incorrectly recalling my own plan. What I should have said is that the add_systemd_unit and add_udev_rule shell functions were to be matured in core/systemd before adding them to the "functions" file of mkinitcpio. I've not seen any bug reports since Tom Gundersen and I wrote those (maybe a year ago?) so perhaps it's time to just go ahead and do that. I'm actually against moving the whole systemd hook into core/mkinitcpio because it then puts mkinitcpio in a situation where it has to be reactionary to backwards incompatible changes to systemd. This kind of dependency has bitten me in the past (though offhand, I don't recall which hook this was relevant to). Maybe Thomas recalls.
Either way, there are 'sd-vconsole' and 'sd-shutdown' already in core/mkinitcpio. I think that if 'sd-resume' will be a separate hook, then either it should be placed here, or all three sd-* hooks should be moved to core/systemd.
Yes, you're right -- this contradicts my previous reply. Ultra long-term, mkinitcpio may lose its shell-based early userspace and only support systemd. That would mean that I ignore my paranoia about backwards incompatible changes just deal with mkinitcpio sometimes needing to move in lockstep with systemd.
(The global alternative -- viability unknown -- is not to make 'sd-resume' a separate hook but to add all this directly from 'systemd' hook.)
Certainly viable. The extra binaries are quite small, and it'd be nice if this "just worked" out of the box. Hope this makes things a bit clearer... d