2007/11/13, Gerrit Renker <gerrit@xxxxxxxxxxxxxx>: > 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 > Then I will let this as it is and after we can working on this. Ok? - 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
