Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes: > Some update on this topic: > the wpi driver also turns off IFF_UP when the radio switch is off, > exept in one case. The attached patch fixes it. > The stream of console message was generated by wpa_supplicant, which > is automatically started by dhcpcd. wpa_supplicant tries to bring the > interface up once per second. Stopping it stops the messages too. > > There's no way to get the radio button events up to userland, execpt with > ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland > script has to pool it to get radio button events). > It looks like this should be hooked up to powerd(4), which already has > notifications for various switches. > > I can look at this, with an implementation for wpi(4), unless someone > objects to the concept. I don't object, but I'm a little unclear on the conceptual model. Is the user pushing the button supposed to be like unplugging a USB interface or removing a PCI device from the bus? Or is it supposed to be like unplugging a cable? The use of IFF_UP feels abusive; historically that's an internal flag that the drive users to signify (to itself) that initialization has been done. It seems to me that when the user pushes the button, the interface should disappear, as if it were a USB interface that was disconnected. Then there's no need for either IFF_UP hackery or special handling. If that's what you mean, sounds good.
Attachment:
pgp0PBB7NdB5V.pgp
Description: PGP signature