Sujith Manoharan wrote: > > Ath9k is a tricky beast to debug, and I think you should > > not remove anything that is remotely useful to debugging > > unless removing it has a real benefit other than just > > decreasing lines of (conditionally compiled) code. > > I am aware that you have rather unique requirements regarding ath9k, Not really. He just wants to have HALF a chance to find issues. I'm sure you understand that ath9k is far from bug free. Until that has changed (don't hold your breath) the driver can not have too much debug information! > removing redundant code will make a difference in > memory-constrained environments like APs. (OpenWRT has DEBUGFS > enabled by default). It is not very wise for ath9k to reduce debug output with the motivation that some users leave it enabled even if they deploy into limited systems and they would actually prefer to have less debugging. If ath9k users have an issue with debugging being too big then THEY can disable it. It seems senseless to delete debugging when the driver is clearly still buggy. It also seems senseless to try to punt to mac80211. It is amazing that Ben's point is not absolutely obvious. One purpose of debugging is to allow and enable consistency checking. Redundant information is by definition neccessary for that. As a compromise, you could suggest a move to a two-level compile time option for debugging. You would enable only what you believe to be adequate for debugging in production systems (wait, what did I just write? oh well..) with the first option, and you would allow the rest of the world to enable complete debugging with the second option. I would support such a scheme. //Peter -- 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
