linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Arjan van de Ven <arjan@linux.intel.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] acpi: button: Provide option for power button to directly signal init
Date: Tue, 4 Feb 2020 16:24:07 -0800	[thread overview]
Message-ID: <20200205002406.GC2968@localhost> (raw)
In-Reply-To: <CAJZ5v0hF2YDVHcvqx_4TaEzuqBKppVG7gZ4nXm_peF75Cfbzmg@mail.gmail.com>

On Thu, Jan 30, 2020 at 10:07:09PM +0100, Rafael J. Wysocki wrote:
> On Sat, Jan 11, 2020 at 3:21 AM Josh Triplett <josh@joshtriplett.org> wrote:
> >
> > Virtual machines and containers often use an ACPI power button event to
> > tell the machine to shut down gracefully.
> >
> > Provide an optional, extremely lightweight way to handle this event by
> > signaling init directly, rather than running a separate daemon (such as
> > acpid or systemd-logind) that adds to startup time and VM image
> > complexity.
> 
> Well, I'm not convinced.

I would be happy to talk through other possible options.

> Even though the patch looks straightforward, the approach really is
> quite not so conceptually and honestly it looks like a band-aid.

I'm not sure what makes it conceptually non-straightforward. I'll freely
admit that it isn't *elegant*. But it also seems inelegant to me to need
to start and run an entire userspace daemon to watch for a key, or to
add such logic into a domain-specific workload's setup and event loop.

I'm entirely open to changing the approach. The goal I'm aiming for is
to allow cloud systems and VMs that signal shutdown via an ACPI power
button to run a more minimal userspace.

> Also I'm not quite sure why the ACPI button driver is the target of
> this and not the input layer, for instance.

I don't have any objections to putting this in another part of the
stack, but input in particular seems like it would potentially affect
the normal event-processing path.

- Josh Triplett

      reply	other threads:[~2020-02-05  0:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11  2:21 [PATCH] acpi: button: Provide option for power button to directly signal init Josh Triplett
2020-01-30 21:07 ` Rafael J. Wysocki
2020-02-05  0:24   ` Josh Triplett [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200205002406.GC2968@localhost \
    --to=josh@joshtriplett.org \
    --cc=arjan@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).