Hi Marcel, > so what overhead is it to have RFKILL just enabled all the time. It is a > small subsystem and the extra code inside the drivers is also not that > much. So what are we really trying to save here? > > I can see your router point, but does it really matter? I don't think so > and some routers allow to switch WiFi off and then they want the RFKILL > switch again. Also what about the LEDS subsystem. The same would apply > and we are not bothering in just enabling it. Yeah I mostly agree with you, but those things do add up. Two kb .text saved means we can handle a few more stations ;) > > Although I don't like all the select business, can't we just have this > > be an invisible option and make it depend on RFKILL? That way, when > > RFKILL isn't selected, ath9k-rfkill won't be compiled, but if it is, it > > will be, and RFKILL can be "default y" and "if EMBEDDED" > > that would be a good compromise. I hate all these extra options that are > basically useless since we enable them anyway. There have already been > various complains about useless options. So at least hide them inside > CONFIG_EMBEDDED if you really think it is worth it. My personal opinion > is that RFKILL support should not be optional. If the hardware supports > it then it should be enabled. Then we'd be back at select, but I don't really care much either way. I agree that this particular option and other driver options for this are fairly useless. On the other hand, if rfkill isn't optional but selected, I lose, udev has been so buggy that I've had to disable rfkill to avoid having it go into an endless loop on some rfkill (re-/de-?)registrations. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
