Dan Williams wrote: > Instead of putting a bunch of > complexity in the kernel and drivers that *already* has to be in > userspace, just punt it out to userspace where it's already done and > works well. That's the way I like things :-) Can the information user space may have to recover include DHCP leases and routes ? I.e., can an rfkill implementation choose to just restart the network interface ? Next: what happens while the device is rfkill'ed ? E.g., is it okay to just remove the interface, so any attempt to configure the interface while it's rfkill'ed would yield an ENODEV ? Basically, could rfkill block/unblock semantics just be equivalent to removal and reloading of the module containing the respective WLAN device driver ? (Ignoring any response time issues for now.) - Werner -- 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
