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

Groups > linux.kernel > #1331291 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 8/9] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-10 17:10 +0100
    Re: [PATCH 8/9] rfkill: Userspace control for airplane mode Dan Williams <dcbw@redhat.com> - 2016-02-10 18:00 +0100
      Re: [PATCH 8/9] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-10 18:20 +0100
        Re: [PATCH 8/9] rfkill: Userspace control for airplane mode João Paulo Rechi Vita <jprvita@gmail.com> - 2016-02-16 16:20 +0100

#1331291 — Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> state. It's just an indicator with no relationship to any of the
> registered rfkill switches, right?

Yes. I'm not sure I'm totally happy with this userspace API.

> I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't
> also
> softblock all switches, otherwise you can set airplane mode all day
> long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually
> enable
> airplane mode at all?

No, this is kinda the point that you could implement your policy in
userspace now.

johannes

[toc] | [next] | [standalone]

#1331335

On Wed, 2016-02-10 at 17:07 +0100, Johannes Berg wrote:
> On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> > I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> > RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> > state. It's just an indicator with no relationship to any of the
> > registered rfkill switches, right?
> 
> Yes. I'm not sure I'm totally happy with this userspace API.
> 
> > I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't
> > also
> > softblock all switches, otherwise you can set airplane mode all day
> > long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually
> > enable
> > airplane mode at all?
> 
> No, this is kinda the point that you could implement your policy in
> userspace now.

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.

Dan

[toc] | [prev] | [next] | [standalone]

#1331349

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.

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.

johannes

[toc] | [prev] | [next] | [standalone]

#1335509

On 10 February 2016 at 12:12, Johannes Berg <johannes@sipsolutions.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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web