Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1341675

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode

From Johannes Berg <johannes@sipsolutions.net>
Newsgroups linux.kernel
Subject Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode
Date 2016-02-24 10:10 +0100
Message-ID <r5DCh-2ih-1@gated-at.bofh.it> (permalink)
References <r51GG-8uQ-19@gated-at.bofh.it> <r51GG-8uQ-23@gated-at.bofh.it> <r5s4b-2dy-21@gated-at.bofh.it> <r5sdQ-2hS-13@gated-at.bofh.it> <r5t0g-2Ub-35@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote:

> Well "the airplane mode" is well defined. It means no intentional
> transmitting at radio frequencies.
> 
> The fact that you are allowed to use WIFI on certain flights does not
> change anything.

Nope, not that simple. Pick up any (contemporary) smartphone and watch
what happens with the airplane mode indicator (the little airplane
icon) when you enable wifi after enabling airplane mode. It stays
there.

Clearly the same logic could then apply to an actual LED (on a system
that's less size-constrained, e.g. a laptop or tablet.)

Thus, the display of "in airplane mode" *does* have policy, and clearly
there's precedent for not disabling the icon or LED when wifi is
enabled, but the kernel shouldn't really impose that. Now, the kernel
has a "safe" default which does what you thought was the "well defined"
airplane mode, but at the same time it's obviously not good enough.

And evidently, the Asus system that this was originally proposed for
has such an LED.

> I see that "airplane mode" trigger might be a tiny bit
> useful... dunno, for a LED near the airplane mode switch, when vendor
> replaced hardware toggle with a key. But policy should have nothing
> to do with that. If you argue additional "policy daemon" is needed
> for that... forget it, that's overdesigned.

See above.

> (Besides, finding all LEDs with given trigger is trivial
> operation. Besides... there should never be more than one).

That *might* actually work. But once a tool has detached the trigger
the information is gone; and tools would have to do that to control the
LED, making recovery from any kind of error difficult.

In any case, I've applied those patches already.

As far as the LED subsystem is concerned, all of this is just another
trigger anyway.

johannes

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Pavel Machek <pavel@ucw.cz> - 2016-02-23 21:50 +0100
  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-23 22:00 +0100
    Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Pavel Machek <pavel@ucw.cz> - 2016-02-23 22:50 +0100
      Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 10:10 +0100
        custom ioctl-based interface to control LED in networking (was Re:  [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-24 11:50 +0100
          Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 12:10 +0100
            Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-24 13:20 +0100
              Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 14:40 +0100
                Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-25 10:10 +0100

csiph-web