Re: suspend / hibernate nomenclature

[Matthew Garrett <mjg@redhat.com>]

On Sun, Mar 08, 2009 at 08:45:59AM +0000, Richard Hughes wrote:
> On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@redhat.com> wrote:
> > We don't have to at all - as far as I've been able to tell, the kernel
> > is utterly consistent in its current usage. The only drivers that emit
> > KEY_SLEEP are either embedded-specific (where it's clearly suspend to
> > RAM and not hibernate), the ACPI driver (where usage in other operating
> > systems is consistent with it being suspent to RAM) and the panasonic
> > and thinkpad drivers which use it consistently. If there's any
> > confusion, it's over the fact that KEY_SUSPEND is is used for suspend to
> > RAM in a (smaller) number of places.
> 
> The fact that we're mapping x->y and y->x is the reason people keep
> getting it wrong.

Sure, doing things differently would have made sense several years ago 
when nobody was relying on this behaviour. We don't have that option now 
- making this change will break things, and we've got no idea how much 
it'll break.

> > I'd suggest reverting these current patches and doing something like the
> > following and then changing any drivers where it's worth clarifying
> > things. This has exactly the same effect with the advantage that no
> > userspace needs to be changed.
> 
> So how do we specify a sleep button where policy is to be decided by
> userspace? For instance, the sleep button on a remote control? Do we
> hardcode policy in the kernel?

Just carry on using KEY_SLEEP for that. We've already got the UI for it.

> > -#define KEY_SLEEP              142     /* SC System Sleep */
> > +#define KEY_SUSPEND_TO_RAM     142     /* SC System Sleep */
> 
> I deliberately avoided using the terms DISK and RAM in the key defines
> used in my patch.

Why? This isn't user-visible. The aim is to reduce confusion amongst 
driver authors, not be consistent with userspace terminology.

> > +/* Deprecated - use KEY_SUSPEND_TO_RAM and KEY_HIBERNATE instead */
> > +#define KEY_SLEEP              KEY_SUSPEND_TO_RAM
> > +#define KEY_SUSPEND            KEY_HIBERNATE
> 
> Yet more confusion. Can't we sort this mess out once and for all? If
> you're that bothered about userspace using the bodged mappings, I
> would suggest changing my patch so that KEY_SLEEP is 247,
> KEY_HIBERNATE is 205 and KEY_SUSPEND is 142.

No, then the behaviour of userspace would depend on whether it had been 
recompiled or not.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html