[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F8D31DB3-94AF-47CC-8091-7B6478983B53@holtmann.org>
Date: Mon, 8 Feb 2016 11:20:24 -0500
From: Marcel Holtmann <marcel@...tmann.org>
To: João Paulo Rechi Vita <jprvita@...il.com>
Cc: Johannes Berg <johannes@...solutions.net>,
"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,
Linux Kernel Mailing List <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
Hi Joa Paulo,
> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.
as explained in an earlier response, the concept Airplane Mode seems to be imposing policy into the kernel. Do we really want have this as a kernel exposed API.
Regards
Marcel
Powered by blists - more mailing lists