public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: "Brown, Len" <len.brown@intel.com>
Cc: Mattia Dongili <malattia@linux.it>, linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/2] Deliver ACPI events upon subscription and implement multiple readers for /proc/acpi/event
Date: Wed, 25 Jan 2006 00:23:01 -0500	[thread overview]
Message-ID: <200601250023.01359.dtor_core@ameritech.net> (raw)
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005D2A09E@hdsmsx401.amr.corp.intel.com>

On Wednesday 25 January 2006 00:09, Brown, Len wrote:
> 
> >On Tuesday 24 January 2006 20:17, Brown, Len wrote:
> >> What's the problem with opening a socket to the user-space acpid --
> >> the way multiple readers work today?
> >>
> >
> >- one does not want to use current implementation of acpid?
> 
> What is better?
> 

Probably nothing at the moment. It does not mean that every program
out there must mimic "legacy" acpid to provice concurrent access
to ACPI events.

> >- one does not want to depend on having acpid running before
> >  starting snooping acpi events?
> 
> For example?

You must ensure that nothing gets to /proc/acpi/events before acpid,
otherwise it won't be able to access it screwing up your system
state.

> 
> >- because allowing multiple readers is a "right thing to do"?
> 
> This is not self-evident, can you give some examples?

"I am trying to read from /proc/acpi/events and there is nothing there"
types of questions on various mailing lists come to my mind.

> 
> The argument against, I suppose, is simply why to add code
> to the kernel when the same feature is already working
> in user-space?
> 

If you remember original code (without registering multiple in-kernel
listeners) I think it was more compact that what is in the kernel
at the moment. Also IIRC current in kernel code may start filling memory
if acpid stops reading events for some reason.

For the record I think multiple listeners are not needed since the only
possible user is input layer and I firmly believe that ACPI should report
keys/buttons using input layer natively so userspace can get uniform
notification of "Sleep" button being pressed no matter whther that button
is controlled by ACPI or it is just another key on USB keyboard.

> The other argument against is why enhance an interface when
> perhaps we should instead consider replacing it altogether...
> 
> >> Dmitry, I don't know how to apply the signed-off thing correctly here,
> 
> If Dmitry is the original author, then the proper format is to put
> 
> From: Dmitry Torokhov <dtor_core@ameritech.net>
> 
> at start of the body of the message where it can over-ride the e-mail author.
> This is documented in Documentation/SubmittingPatches.
>

I'd say it is only valid if original patch is mostly intact. If it was
heavily reworked/enhanced I think mentioning the original author in
description is fine but authorship belongs the person who reworked the
code. Just IMHO.

-- 
Dmitry

  reply	other threads:[~2006-01-25  5:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25  5:09 [PATCH 0/2] Deliver ACPI events upon subscription and implement multiple readers for /proc/acpi/event Brown, Len
2006-01-25  5:23 ` Dmitry Torokhov [this message]
2006-01-25  9:54   ` Mattia Dongili
2006-01-26 17:38     ` Thomas Renninger
  -- strict thread matches above, loose matches on Subject: below --
2006-01-25  1:17 Brown, Len
2006-01-25  1:46 ` Dmitry Torokhov
2006-01-25  8:16   ` Mattia Dongili
2006-01-24 23:14 Mattia Dongili

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=200601250023.01359.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=malattia@linux.it \
    /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