On Tue, May 16, 2006, Jouni Malinen wrote: > Some hardware designs disable the radio in hardware, some > don't.. In other words, the behavior would not be consistent > between hardware designs unless the radio would be disabled > unconditionally in software-processed case. I would like to > be able to trust on the rfkill to really kill the radio > regardless of whether the user space mechanism is in place or > not, i.e., I see this as a function that can be used to > disable radio in environments were use of wireless devices is > not allowed for some reason. > > Sending an event to user space would be a good additional > indication that the radio was disabled. If user space wants > to do something first, I would think that doing this with > full software control (i.e., not depending on any particular > hardware button and just having a UI mechanism for triggering > this) would allow more consistent behavior.
Sounds like this is the popular option - I agree that immediate radio-off is the "safe" way to go here as at least the driver can guarantee that the radio is disabled no matter the userspace config. Does someone want to put their hand up and specify the userspace interface here and now so we all keep to a standard ? Working as an input device as David suggested seems to give us the most flexibility. Regards, Mark Wallis E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
