On Sat, 2009-08-01 at 23:25 +0100, Matthew Garrett wrote: > On Sat, Aug 01, 2009 at 03:11:25PM -0700, Marcel Holtmann wrote: > > > and that is what it should NOT imply. The policy if it applies to all > > internal devices, all devices in general or just WiFi or Bluetooth for > > example is up to the user. > > > > We are NOT going to have any kind of RFKILL policy in the kernel in the > > future. We will remove rfkill-input once we have a proper userspace > > solution (aka rfkilld or similar). > > We seem to be talking at cross purposes here. My objection to the name > KEY_RFKILL is that it gives no indication what it's meant to be or why > it's different to KEY_WLAN. KEY_RFKILL implies that it's the only input > component that an rfkill policy agent needs to listen to, which isn't > the case. Heh, yeah, I can kinda agree with both of you. We really should've named KEY_WLAN KEY_RFKILL_WLAN instead, etc, and then both versions would be less ambiguous. AFAIU, Marcel's argument is that policy might not be "ALL", but cycling through technology combinations, and your (Matthew's) argument is that just naming it without the _ALL would imply that KEY_WLAN could be related to something other than rfkill. Can we name it KEY_RFKILL, and add a comment to the header file about what it is? I.e. a "technology-independent RF toggle button" or so? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
