Quoting Leandro:
| 2007/11/8, Gerrit Renker <[EMAIL PROTECTED]>:
| > | +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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
