On Mon, Jan 11, 2016 at 8:02 PM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > On Mon, 2016-01-11 at 14:21 -0500, Josh Boyer wrote: >> On Sun, Jan 10, 2016 at 7:54 AM, Bastien Nocera <bnocera@xxxxxxxxxx> >> wrote: >> > From: Bastien Nocera <hadess@xxxxxxxxxx> >> > >> > As noted in https://www.kernel.org/doc/Documentation/rfkill.txt >> > rfkill-input is deprecated, and rfkill keys are handled in user- >> > space. >> >> That may be what the document says, but the Kconfig at least seems to >> imply something else. > > What says that in the Kconfig? The fact that disabling it is still enforced behind CONFIG_EXPERT upstream. It's certainly likely that people are terrible at cleaning up and it should have been done long ago, but it wasn't. > This is the relevant commit which explains what rfkill-input is used > for (basically, if you don't have a desktop environment and you still > want the keys to work): > > commit c64fb01627e24725d1f9d535e4426475a4415753 > Author: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Date: Tue Jun 2 13:01:38 2009 +0200 > > rfkill: create useful userspace interface > > The new code added by this patch will make rfkill create > a misc character device /dev/rfkill that userspace can use > to control rfkill soft blocks and get status of devices as > well as events when the status changes. > > Using it is very simple -- when you open it you can read > a number of times to get the initial state, and every > further read blocks (you can poll) on getting the next > event from the kernel. The same structure you read is > also used when writing to it to change the soft block of > a given device, all devices of a given type, or all > devices. > > This also makes CONFIG_RFKILL_INPUT selectable again in > order to be able to test without it present since its > functionality can now be replaced by userspace entirely > and distros and users may not want the input part of > rfkill interfering with their userspace code. We will > also write a userspace daemon to handle all that and > consequently add the input code to the feature removal > schedule. The feature removal schedule doesn't exist anymore and hasn't for a number of years. Even if it did, the feature is clearly not removed. Out of curiosity, which daemon(s) handle the "new" interface? > In order to have rfkilld support both kernels with and > without CONFIG_RFKILL_INPUT (or new kernels after its > eventual removal) we also add an ioctl (that only exists > if rfkill-input is present) to disable rfkill-input. > It is not very efficient, but at least gives the correct > behaviour in all cases. > > Signed-off-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Acked-by: Marcel Holtmann <marcel@xxxxxxxxxxxx> > Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx> > > Does it really make sense to cater for that use? No. I don't really care either way. But did you even read the rest of my original email? I can't turn it off without turning on CONFIG_EXPERT, and I'm not going to do that. Also, did you test your patch on e.g. Fedora Workstation? So perhaps pursue dropping that requirement upstream, or just deleting the whole thing entirely. It was originally scheduled to be removed in 2.6.33, which was 6 years ago. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
