From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 4 Sep 2008 08:15:11 +0200

quoted text
> This is an update with regard to Wei's comments. I have re-synched 
> 
> 	git://eden-feed.erg.abdn.ac.uk/dccp_exp		[subtree `dccp']
> 	http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=shortlog;h=dccp
> 
> Also did some testing with a client that only supports CCID 2/3 talking to a client supporting
> CCID 2/3/4. They could still negotiate and settle for a common CCID.

I pulled and resolved all of the conflicts, but this build warning I'm
now getting from ccid3.h has got to go:

/*
 * The t_delta parameter (RFC 3448, 4.6): delays of less than %USEC_PER_MSEC are
 * rounded down to 0, since sk_reset_timer() here uses millisecond granularity.
 * Hence we can use a constant t_delta = %USEC_PER_MSEC when HZ >= 500. A coarse
 * resolution of HZ < 500 means that the error is below one timer tick (t_gran)
 * when using the constant t_delta  =  t_gran / 2  =  %USEC_PER_SEC / (2 * HZ).
 */
#if (HZ >= 500)
# define TFRC_T_DELTA		   USEC_PER_MSEC
#else
# define TFRC_T_DELTA		   (USEC_PER_SEC / (2 * HZ))
#warning Coarse CONFIG_HZ resolution -- higher value recommended for TFRC.
#endif

Don't warn about crap like this, instead convert the code over to hrtimers.

This kernel being built, even with HZ=100, can do nanosecond timers on
my systems, but that's only if you would make proper use of them.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html