On Monday 12 January 2009 22:13:13 Werner Almesberger wrote: > 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.) No. If you are in an rfkill situation, you're not required to kill the receiver. (However, currently most (all?) devices kill both TX and RX). So I think completely killing the interface is the wrong way to go. And I don't think we should care about stuff above the MAC layer, too. If the user hits rfkill, he should _expect_ all upper layer connections to break (DHCP, TCP or whatever). That's a basic assumption about rfkill. The default timeouts will handle that just fine. In any way, this is nothing the kernel has to care about. It's userspace business, if any. -- Greetings, Michael. -- 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
