[arch-projects] [mkinitcpio] [PATCH] Add sd-resume hook.

[Ivan Shapovalov]

On Tuesday 26 August 2014 at 19:02:50, Dave Reisner wrote:	
> 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 at .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

Hello again,

systemd 217 seems to be in testing now, so what's the status of this?
We should either merge this hook to core/mkinitcpio or add the equivalent
code to 'systemd' hook.

(I'm for the second approach, actually...)

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.archlinux.org/pipermail/arch-projects/attachments/20141031/3097ef16/attachment.bin>