Quoting Leandro: | 2007/11/8, Gerrit Renker <gerrit@xxxxxxxxxxxxxx>: | > | +config IP_DCCP_CCID4_DEBUG | > | + bool "CCID4 debugging messages" | > | + depends on IP_DCCP_CCID4 | > <snip> | > | +# The TFRC Library: currently has CCID 3 and CCID 4 as customer | > | config IP_DCCP_TFRC_LIB | > | - depends on IP_DCCP_CCID3 | > | + depends on IP_DCCP_CCID3 || IP_DCCP_CCID4 | > | def_tristate IP_DCCP_CCID3 | > | | > | config IP_DCCP_TFRC_DEBUG | > Suggestion: if CCID3 is not compiled as module, there will currently be | > no TFRC debugging output for dccp_tfrc_lib when only CCID4 is enabled. | > Something like | > | > config IP_DCCP_TFRC_DEBUG | > bool | > default y if IP_DCCP_CCID3_DEBUG || IP_DCCP_CCID4_DEBUG | > | > would enable this. | > | > On the other hand, the number of `debugs' keeps continually growing. | > Maybe it is possible to just use tfrc_debug for everything that speaks | > TFRC, otherwise we currently have | > * tfrc_debug to enable debug messages in dccp_tfrc_lib | > * ccid3_debug " dccp_ccid3 | > * ccid4_debug " dccp_ccid4 | > * dccp_debug to see the rest | > - | | Yes, it is better to have tfrc_debug for everything related to TFRC. I | will also fix the IP_DCCP_TFRC_DEBUG kconfig option like you | suggested. | Please do as you see fit, but don't worry too much at this stage - this can all be resolved later (i.e. further abstraction can be done later). - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
