Sorry for the delay in replying. >> One future patch will need to modify this file, but now it's really an >> exact copy. >> >> > Basically the rule with a patch set is that all the patches should > make sense together. > > It may well be that it makes sense to make a copy, but if you want to > do this then present it with the patch that then modifies it. > I agree with Ian's point. At the moment I can only see patch 5/5 modifying this file (adding documentation); from my reading of RFC 4828/5622 it seems not necessary to use 'tfrc_sp' variants of the functions computing X. The situation will be better as soon as the patches are in their own subtree. Currently there is a benefit in using separate files: the tfrc library does not support a sender-based variant of TFRC, hence requires further work and/or a decision to support a sender-bsed variant of CCID-3/4 only in an experimental subtree - this requires input and discussion. -- 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
