From: Pavel Machek <pavel@ucw.cz>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: rpurdie@rpsys.net, j.anaszewski@samsung.com,
linux-leds@vger.kernel.org,
"João Paulo Rechi Vita" <jprvita@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Darren Hart" <dvhart@infradead.org>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-api@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@endlessm.com,
"João Paulo Rechi Vita" <jprvita@endlessm.com>
Subject: Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)
Date: Wed, 24 Feb 2016 13:14:21 +0100 [thread overview]
Message-ID: <20160224121420.GA5627@amd> (raw)
In-Reply-To: <1456311697.2050.23.camel@sipsolutions.net>
On Wed 2016-02-24 12:01:37, Johannes Berg wrote:
> On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
>
> > If you want different trigger, implement different trigger. If you
> > want to indicate all but wifi, implement all but wifi, and then
> > userspace can select it by writing trigger name.
>
> This is still mostly a strawman, since userspace cannot have a database
> of LEDs that indicate airplane mode.
Why would it need to? It could look at default triggers for the led if
it really wanted to.
> I'm sure you'd also not like to see 2**7 triggers implemented in rfkill
> to cover all the possibilities.
Are all the possibilities useful? I assumed about 2 are. If you need
2**7 of them, LED triggers can have parameters.
> > If you want complete
> > userspace control, fine, but we have standard interface and it is not
> > ioctl.
>
> The "standard interface" is usable if you really just want to driver a
> single LED and you know which one.
>
> I think you're looking at this the wrong way, focusing too much on the
> LED aspect.
>
> Really what you have here is a concept of "airplane mode", and that
> concept is specific to the rfkill subsystem. This happens to affect
> mostly an LED trigger, today, but as a concept it's something that
> *should* be managed within the rfkill subsystem.
How is that concept used outside the LEDs? What semantics does
"airplane mode" have? You tried to explain "airplane mode" is not well
defined up in this thread...
> > Besides, the series really should have been Cc-ed to LED
> > people, too.
>
> That's simply unreasonable, you're essentially saying that any user of
> any kernel infrastructure should be Cc'ed to the implementer of that
> infrastructure... 9/10 patches in this series aren't even LED
> > specific,
I'm not saying that. I'm saying that LED maintainers should be Cced,
to keep the interfaces consistent.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2016-02-24 12:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 16:36 [PATCHv2 00/10] RFKill airplane-mode indicator João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 01/10] rfkill: Improve documentation language João Paulo Rechi Vita
[not found] ` <1456159001-20307-1-git-send-email-jprvita-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
2016-02-22 16:36 ` [PATCHv2 02/10] rfkill: Remove extra blank line João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 03/10] rfkill: Point to the correct deprecated doc location João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 04/10] rfkill: Move "state" sysfs file back to stable João Paulo Rechi Vita
2016-02-23 20:45 ` Pavel Machek
2016-02-22 16:36 ` [PATCHv2 05/10] rfkill: Factor rfkill_global_states[].cur assignments João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 06/10] rfkill: Add documentation about LED triggers João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 07/10] rfkill: Create "rfkill-airplane-mode" LED trigger João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 08/10] rfkill: Use switch to demux userspace operations João Paulo Rechi Vita
[not found] ` <1456159001-20307-9-git-send-email-jprvita-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
2016-02-26 17:59 ` Jouni Malinen
2016-02-29 22:30 ` João Paulo Rechi Vita
2016-02-29 22:39 ` Jouni Malinen
2016-03-01 13:43 ` Johannes Berg
[not found] ` <1456839787.3926.20.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2016-03-01 16:15 ` João Paulo Rechi Vita
2016-03-08 14:01 ` João Paulo Rechi Vita
2016-02-22 16:36 ` [PATCHv2 09/10] rfkill: Userspace control for airplane mode João Paulo Rechi Vita
2016-02-22 19:31 ` [PATCHv3] " João Paulo Rechi Vita
2016-02-23 20:45 ` [PATCHv2 09/10] " Pavel Machek
2016-02-23 20:55 ` Johannes Berg
2016-02-23 21:45 ` Pavel Machek
2016-02-24 9:01 ` Johannes Berg
2016-02-24 10:46 ` custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek
2016-02-24 11:01 ` Johannes Berg
2016-02-24 12:14 ` Pavel Machek [this message]
2016-02-24 13:31 ` Johannes Berg
2016-02-25 9:06 ` Pavel Machek
2016-02-22 16:36 ` [PATCHv2 10/10] rfkill: Notify userspace of airplane-mode state changes João Paulo Rechi Vita
2016-02-22 17:00 ` [PATCHv2 00/10] RFKill airplane-mode indicator Dan Williams
2016-02-22 19:35 ` João Paulo Rechi Vita
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=20160224121420.GA5627@amd \
--to=pavel@ucw.cz \
--cc=davem@davemloft.net \
--cc=dvhart@infradead.org \
--cc=j.anaszewski@samsung.com \
--cc=johannes@sipsolutions.net \
--cc=jprvita@endlessm.com \
--cc=jprvita@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@endlessm.com \
--cc=netdev@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rpurdie@rpsys.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).