| > | > 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 | > | > - <snip> | | Then I will let this as it is and after we can working on this. Ok? | Yes that's absolutely fine. I just checked: none of the trees (origin|dccp|ccid4) currently uses tfrc_pr_debug(), so this is something to be investigated when thinking of sharing code between ccid4/ccid3.
Either that macro / variable should then be obsoleted, or it could be shared between CCID3/4. -- - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
