[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1455123205.19821.34.camel@redhat.com>
Date: Wed, 10 Feb 2016 10:53:25 -0600
From: Dan Williams <dcbw@...hat.com>
To: Johannes Berg <johannes@...solutions.net>,
João Paulo Rechi Vita <jprvita@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Darren Hart <dvhart@...radead.org>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-api@...r.kernel.org,
linux-doc@...r.kernel.org, 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 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
Powered by blists - more mailing lists