On 5/28/09, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > 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. > > Signed-off-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> How should userspace test CONFIG_RFKILL_INPUT to determine whether it's safe to start the daemon? With the old core, debian-eeepc scripts check if the module rfkill-input exists (which should work even if it's built in). If it exists, the scripts don't perform any rfkill actions. (Yeah, according to the doc this is not allowed because the scripts don't use "claim", but you can see how it's useful). The new rfkill-input isn't a module, so I'm not sure how your daemon would test for it. Thanks Alan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
