All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 16/25] Share ccid3_hc_rx_sock struct and ccid3_hc_rx_sk function via tfrc_ccids
Date: Thu, 01 Nov 2007 11:00:15 +0000	[thread overview]
Message-ID: <200711011100.15295@strip-the-willow> (raw)
In-Reply-To: <200710312131.50615.leandroal@gmail.com>

I think we need to get back to deciding on a naming scheme for the structs. It is not
your fault, but with the current scheme the names become extremely cryptic:

|  + *  @tfrchcrx_last_counter  -  Tracks window counter (RFC 4342, 8.1)
|  + *  @tfrchcrx_state  -  Receiver state, one of %tfrc_hc_rx_states
|  + *  @tfrchcrx_bytes_recv  -  Total sum of DCCP payload bytes
|  + *  @tfrchcrx_x_recv  -  Receiver estimate of send rate (RFC 3448, sec. 4.3)
|  + *  @tfrchcrx_rtt  -  Receiver estimate of RTT
|  + *  @tfrchcrx_last_feedback  -  Time at which last feedback was sent
|  + *  @tfrchcrx_hist  -  Packet history, exported by TFRC module
|  + *  @tfrchcrx_li_hist  -  Loss Interval database, exported by TFRC module
|  + *  @tfrchcrx_s  -  Received packet size in bytes
|  + *  @tfrchcrx_pinv  -  Inverse of Loss Event Rate (RFC 4342, sec. 8.5)
|  + */

Similar thing with the #defines - my eyes fail to parse this:
|   #define ccid3_hc_tx_sk tfrc_hc_tx_sk
|   
|  +#define ccid3_hc_rx_sock tfrc_hc_rx_sock
|  +#define ccid3hcrx_s tfrchcrx_s
|  +#define ccid3hcrx_x_recv tfrchcrx_x_recv
|  +#define ccid3hcrx_pinv tfrchcrx_pinv
|  +#define ccid3hcrx_last_feedback tfrchcrx_last_feedback
|  +#define ccid3hcrx_bytes_recv tfrchcrx_bytes_recv
|  +#define ccid3hcrx_last_counter tfrchcrx_last_counter
|  +#define ccid3hcrx_rtt tfrchcrx_rtt
|  +#define ccid3hcrx_s tfrchcrx_s
|  +#define ccid3hcrx_hist tfrchcrx_hist
|  +#define ccid3hcrx_li_hist tfrchcrx_li_hist

My suggestion is to use something like
	* `ttx_' for TFRC TX related structs/operations/fields
	* `trx_' for  "   RX  "             "
	* Arnaldo's scheme for the CCIDs 
		-- c3rx_ / c4rx_ for RX structs/fields
		-- c3tx_ / c4tx_ for TX structs/fields

Of course that costs work. But now is probably the best time to change it - so better
get it cleaned up before passing it on to Arnaldo.

  reply	other threads:[~2007-11-01 11:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-01  0:31 [PATCH 16/25] Share ccid3_hc_rx_sock struct and ccid3_hc_rx_sk function via tfrc_ccids Leandro
2007-11-01 11:00 ` Gerrit Renker [this message]
2007-11-01 21:58 ` Łeandro Sales
2007-11-08 10:28 ` Gerrit Renker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711011100.15295@strip-the-willow \
    --to=gerrit@erg.abdn.ac.uk \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.