Jan Engelhardt wrote: > On Thursday 2010-04-22 12:46, Patrick McHardy wrote: >> Jan Engelhardt wrote: >>> Netfilter traditionally used debug prints that were omitted unless >>> someone explicitly defined DEBUG. Recently that has no longer been the >>> case (see explanation in commit v2.6.30-rc2-184-g4ccb457). Switch our >>> pr_debug calls to pr_devel. >> The intention of CONFIG_DYNAMIC_DEBUG is exactly to make those debug >> statements available dynamically. I presume the mentioned distribution >> had a reason to enable that option. Why should we undermine that by >> turning debug statements into "devel" statements? > > Once upon a time, most of the Netfilter debug statements read like: > > #ifdef TURNMEON > #define duprintf(...) printk(...) > #else > #define duprintf(...) > #endif > > So the intention was to have a behavior that requires a developer to > explicitly turn on debugging in source code. By adding a line like > #define IP_DEBUG_FIREWALL at the start. (I explicitly exclude > blocks like #ifdef CONFIG_ in this consideration.) > > When pr_debug became available, parts of the netfilter code moved to > pr_debug, as that behaved just the same - the only change was that the > variable was now named DEBUG across the entire kernel source rather than > IP_DEBUG_FIREWALL - whatever the actual name was. > > Enter pr_devel, which suddenly turned all pr_debug calls into pieces > that would expand despite DEBUG being undefined - and that seemed > contrary to the original intent. The code is only expanded when CONFIG_DYNAMIC_DEBUG is enabled. Which is exactly what this option is there for. I've noticed you already included a few pr_devel() statements in a recent submission. I'd rather convert those to pr_debug() -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
