linux-kernel - Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+A7VXWuMfGpLCyv+veq1GxMzZe+P1F99470KT7B_Q3+6v9fdQ@mail.gmail.com>
Date:	Tue, 16 Feb 2016 10:12:45 -0500
From:	João Paulo Rechi Vita <jprvita@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Dan Williams <dcbw@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Darren Hart <dvhart@...radead.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	platform-driver-x86@...r.kernel.org, linux-api@...r.kernel.org,
	linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux@...lessm.com,
	João Paulo Rechi Vita <jprvita@...lessm.com>
Subject: Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

On 10 February 2016 at 12:12, Johannes Berg <johannes@...solutions.net> wrote:
> On 2016-02-10 17:53, Dan Williams wrote:
>>
>> Yeah, I get that now.  It's just that to me, something called
>> "AIRPLANE_MODE_CHANGE" seems like it should actually change airplane
>> mode on/off, which implies killing radios.  I wouldn't have had the
>> problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE, which makes it
>> clear this is simply an indicator and has no actual effect on anything
>> other than a LED.
>

I also agree the AIRPLANE_MODE_INDICATOR_* prefix makes things more
clear here. Thanks for the feedback, Dan!

>
> Yeah, I agree. I'm not even sure that it's a good idea to subsume this into
> the regular operations in the API, although that's obviously the easiest
> extension. I'll need to think about that a bit more with the code at hand
> though.
>

Initially I have thought about creating and additional RFKill switch
for that, but I think it would be a bit hackish since we would have to
treat it specially in sysfs attributes and probably other places, and
userspace would also need a special case when going through the list
of RFKill switches in the system. The proposed solution has equivalent
semantics to an RFKill switch, is backward-compatible (users would
only ignore the unknown operations and evens -- although gsd has a
"default:" case to abort execution on an unknown event) and does not
extend the RFKill event struct.

One alternative would be to move the control point to a separate
device, like /dev/rfkill-airplane-mode, but I'm not sure this is a
very elegant approach. Anyway, I'm open to work on changes to the API,
but it would be great if you could at least pick or reject the
non-polemical patches of the series, so I don't need to carry them
anymore.

--
João Paulo Rechi Vita
http://about.me/jprvita