From: Stefani Seibold <stefani@seibold.net>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
davem@davemloft.net, netdev@vger.kernel.org,
eric.dumazet@gmail.com, shemminger@vyatta.com
Subject: Re: [PATCH] new UDPCP Communication Protocol
Date: Sun, 02 Jan 2011 22:33:13 +0100 [thread overview]
Message-ID: <1294003993.5675.3.camel@wall-e> (raw)
In-Reply-To: <AANLkTi=7M=gSgBjcrCVEj+GKZ5cf5t4MPqm6r9NGr=MZ@mail.gmail.com>
Am Sonntag, den 02.01.2011, 21:48 +0200 schrieb Daniel Baluta:
> Hello,
>
> I have some style comments, please read below.
>
> > +struct udpcp_statistics {
> > + unsigned int txMsgs; /* Num of transmitted messages */
> > + unsigned int rxMsgs; /* Num of received messages */
> > + unsigned int txNodes; /* Num of receiver nodes */
> > + unsigned int rxNodes; /* Num of transmitter nodes */
> > + unsigned int txTimeout; /* Num of unsuccessful transmissions */
> > + unsigned int rxTimeout; /* Num of partial message receptions */
> > + unsigned int txRetries; /* Num of resends */
> > + unsigned int rxDiscardedFrags; /* Num of discarded fragments */
> > + unsigned int crcErrors; /* Num of crc errors detected */
>
> Is there any strong reason to have this camel case naming?
> I would prefer tx_msgs, rx_msgs etc..
>
This cannot be fixed for compatiblity reasons.
> > +struct udpcp_dest {
> > + struct list_head list;
> > + struct sk_buff_head xmit;
> > + unsigned long tx_time;
> > + unsigned long rx_time;
> > + u32 txTimeout;
> > + u32 rxTimeout;
>
> Here you have mixed naming conventions. I guess
> tx_timeout will fit in better than txTimeout.
>
> > + u32 txRetries;
> > + u32 rxDiscardedFrags;
> > + struct sk_buff *xmit_wait;
> > + struct sk_buff *xmit_last;
> > + struct sk_buff *recv_msg;
> > + struct sk_buff *recv_last;
> > + struct udpcphdr lastmsg;
> > + struct ipcm_cookie ipc;
> > + struct flowi fl;
> > + struct rtable *rt;
> > + __be32 addr;
> > + __be16 port;
> > + u16 msgid;
> > + u8 use_flag;
> > + u8 insync;
> > + u8 ackmode;
> > + u8 chkmode;
> > + u8 try;
> > + u8 acks;
> > + struct udp_sock udpsock;
> > + struct sk_buff_head assembly;
> > + u32 assembly_len;
> > + struct udpcp_dest *assembly_dest;
> > + wait_queue_head_t wq;
> > + struct list_head destlist;
> > + struct list_head udpcplist;
> > + struct timer_list timer;
> > + struct udpcp_statistics stat;
> > + u32 pending;
> > + unsigned long tx_timeout;
> > + unsigned long rx_timeout;
> > + void (*udp_data_ready) (struct sock *sk, int bytes);
> > + u8 ackmode;
> > + u8 chkmode;
> > + u8 maxtry;
> > + u8 acks;
> > + u8 timeout;
> > +/* overall UDPCP statistics */
> > +static atomic_t udpcp_txMsgs;
> > +static atomic_t udpcp_rxMsgs;
> > +static atomic_t udpcp_txNodes;
> > +static atomic_t udpcp_rxNodes;
> > +static atomic_t udpcp_txTimeout;
> > +static atomic_t udpcp_rxTimeout;
> > +static atomic_t udpcp_txRetries;
> > +static atomic_t udpcp_rxDiscardedFrags;
> > +static atomic_t udpcp_crcErrors;
>
> same here.
>
I think there is no nameing convention in linux, as i know it is a
developer decision.
next prev parent reply other threads:[~2011-01-02 21:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-02 15:31 [PATCH] new UDPCP Communication Protocol stefani
2011-01-02 16:34 ` Eric Dumazet
2011-01-02 19:48 ` Daniel Baluta
2011-01-02 21:33 ` Stefani Seibold [this message]
2011-01-02 21:40 ` Jesper Juhl
2011-01-02 19:55 ` Jesper Juhl
2011-01-02 21:46 ` Stefani Seibold
2011-01-02 22:04 ` Jesper Juhl
2011-01-02 22:21 ` Stefani Seibold
2011-01-02 20:16 ` Rémi Denis-Courmont
2011-01-02 21:37 ` Stefani Seibold
2011-01-02 21:55 ` Eric Dumazet
2011-01-02 22:16 ` Stefani Seibold
2011-01-02 22:31 ` Eric Dumazet
-- strict thread matches above, loose matches on Subject: below --
2011-01-11 16:48 stefani
2011-01-11 16:48 ` stefani
2011-01-11 17:01 ` Eric Dumazet
2011-01-11 20:50 ` Stefani Seibold
2011-01-11 20:52 ` David Miller
2011-01-11 21:14 ` Stefani Seibold
2011-01-11 21:19 ` David Miller
2011-01-11 21:41 ` Stefani Seibold
2011-01-11 21:46 ` Eric Dumazet
2011-01-11 22:23 ` Stefani Seibold
2011-01-11 21:30 ` Eric Dumazet
2011-01-11 21:40 ` Stefani Seibold
2011-01-11 21:06 ` Eric Dumazet
2011-01-03 14:34 stefani
2011-01-03 14:34 ` stefani
2011-01-02 22:39 stefani
2011-01-02 22:39 ` stefani
2011-01-02 22:49 ` Eric Dumazet
2011-01-02 22:55 ` Stefani Seibold
2011-01-02 23:04 ` Jesper Juhl
2011-01-03 9:08 ` Stefani Seibold
2011-01-03 9:27 ` Eric Dumazet
2011-01-03 9:54 ` Stefani Seibold
2011-01-03 10:39 ` Eric Dumazet
2011-01-03 14:08 ` Stefani Seibold
2011-01-01 21:44 stefani
2011-01-01 22:23 ` Eric Dumazet
2011-01-02 11:17 ` Stefani Seibold
2011-01-02 11:33 ` Eric Dumazet
2011-01-02 11:57 ` Stefani Seibold
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=1294003993.5675.3.camel@wall-e \
--to=stefani@seibold.net \
--cc=akpm@linux-foundation.org \
--cc=daniel.baluta@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/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.