[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 08 Sep 2008 17:32:50 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: gerrit@....abdn.ac.uk
Cc: acme@...hat.com, dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: net-next-2.6 [pull-request] [PATCH 0/37] dccp: Revised set of
feature-negotiation patches
From: Gerrit Renker <gerrit@....abdn.ac.uk>
Date: Thu, 4 Sep 2008 08:15:11 +0200
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists