On 12/19/06, Ian McDonald <ian.mcdonald@xxxxxxxxxxx> wrote:
On 12/20/06, Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> wrote:
> The loop comes because dccp_ccid3.ko needs symbols provided by
> dccp_tfrc_lib.ko, so if we try to export ccid3_pr_debug to be used by
> dccp_tfrc_lib.ko we'll get the loop, so I guess the right thing to do
> is to introduce tfrc_pr_debug, that will give us more flexibility,
> allowing one to select ccid3 debugging, tfrc debugging, both or none.
>
> - Arnaldo
>
I think the right thing to do is not to introduce another level of debugging.
People want to debug or they don't in my opinion. I think we should do
away with ccid3_pr_debug and ccid2_pr_debug. I always turn them all on
or all off when working with testing (or add my own statements in).
If the way to go is a boolean, i.e. to debug or not to debug we have
to remove ccid{2,3}_pr_debug and stick to using dccp_pr_debug
everywhere, that would eliminate the loop as dccp.ko doesn't directly
uses any code from dccp_ipv[4,6]. ccid[2, 3] or tfrc.
But I think that being able to debug just the dccp core, or just
ccid3, or just tfrc is better.
- Arnaldo
-
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
