Hi Dan, > > > > 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. > > > > > > Maybe we should add an ioctl that disables rfkill-input if present. > > > > I am against it. Can we just add a module parameter that allows us to > > disable it. I am against cluttering a new interface with legacy stuff > > since we are removing rfkill-input and replacing it by rfkilld anyway in > > a near future (meaning when I am back from vacation). > > Module parameter to what? Module parameters are almost always the wrong > thing to do. Or, just don't built rfkill_input it into your kernel we will make rfkill-input go away. This is just for the interim to detect if rfkill-input is supported by the kernel or not. And it allows to compile it into the kernel and disable it via modprobe.conf. Regards Marcel -- 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
