[systemd-devel] [RFC] [PATCHv3 3/3] resume-generator: add a generator for instantiating the resume unit.

[Lennart Poettering]

On Mon, 25.08.14 22:27, Ivan Shapovalov (intelfx100 at gmail.com) wrote:

> On Monday 25 August 2014 at 19:58:52, Lennart Poettering wrote:	
> > [...]
> > 
> > One more question though, regarding the terminology. So far we used the
> > following terms:
> > 
> >     "suspend" → means suspend-to-ram
> >     "hibernate" → means suspend-to-disk
> >     "hybrid-sleep" → means both STR + STD combined
> >     "sleep" → a generic term for all of the above.
> > 
> > Now, I do wonder how we should call the operation when we come back from
> > the sleep states.
> > 
> > To me "resume" would probably most clearly be the reverse of "suspend",
> > but you actually are looking for the reverse of "hibernate" here. 
> > 
> > The reverse of "sleep" would be "wake" I figure...
> > 
> > On the kernel side the terminology for all of this is completely
> > random. Especially given that the input layer names some keys with the
> > precise opposite of what the PM layer calls the operations... But we
> > really should try to clean this up a bit when exposing this in
> > userspace...
> > 
> > So, dunno, what's the antonym of "hibernate"? SOmething like "thaw"
> > maybe? Any native english speakers with ideas?
> 
> I've called it "resume" just because the kernel command line parameter
> is named "resume=", kernel messages use the term "resume", the arch initramfs
> hook is also named "resume" and so on... This may be inconsistent globally,
> but the opposite of hibernation is called "resume" pretty much everywhere.
> 
> However, suggestions welcome.


Hmm, the fact that the kernel cmdline option is named "resume" is
probably a strong indication we should stick to that nomenclature, after
all that's UI already in away...

But maybe call it "systemd-hibernate-resume at .service" and
systemd-hibernate-resume-generator or so?

Longer to type but more precise, and I figure nobody has to type this
ever anyway...

Lennart

-- 
Lennart Poettering, Red Hat