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 > > > > [email protected] > > > > 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...
Yep, I've largely understood the situation. So, what will we do? If putting this into 'systemd' is OK, then I'd prefer this way. -- Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part.
