All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>,
	Jon Maloy <jon.maloy@ericsson.com>
Subject: Re: [PATCH net-next 10/10] tipc: refactor accept() code for improved readability
Date: Fri, 7 Dec 2012 14:56:29 -0500	[thread overview]
Message-ID: <20121207195629.GB27639@windriver.com> (raw)
In-Reply-To: <20121207194226.GB30339@hmsreliant.think-freely.org>

[Re: [PATCH net-next 10/10] tipc: refactor accept() code for improved readability] On 07/12/2012 (Fri 14:42) Neil Horman wrote:

> On Fri, Dec 07, 2012 at 09:28:18AM -0500, Paul Gortmaker wrote:
> > In TIPC's accept() routine, there is a large block of code relating
> > to initialization of a new socket, all within an if condition checking
> > if the allocation succeeded.
> > 
> > Here, we simply factor out that init code within the accept() function
> > to its own separate function, which improves readability, and makes
> > it easier to track which lock_sock() calls are operating on existing
> > vs. new sockets.
> > 
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> > ---
> >  net/tipc/socket.c | 93 +++++++++++++++++++++++++++++--------------------------
> >  1 file changed, 49 insertions(+), 44 deletions(-)
> > 
> > diff --git a/net/tipc/socket.c b/net/tipc/socket.c
> > index 38613cf..56661c8 100644
> > --- a/net/tipc/socket.c
> > +++ b/net/tipc/socket.c
> > @@ -1507,6 +1507,53 @@ static int listen(struct socket *sock, int len)
> >  	return res;
> >  }
> >  
> > +static void tipc_init_socket(struct sock *sk, struct socket *new_sock,
> > +			     struct sk_buff *buf)
> > +{
> Can you rename this to something more specific to its purpose?  tipc_init_socket
> makes me wonder why you're not calling it internally from tipc_create.  This
> seems more like a tipc_init_accept_sock, or some such.  Alternatively, since
> you're ony using it from your accept call, you might consider not factoring it
> out at all, and just reversing the logic in your accept function so that you do:
> 
>  res = tipc_create(...)
>  if (res)
> 	goto exit;
>  <rest of tipc_init_socket goes here>
> 
> That gives you the same level of readability, without the additional potential
> call instruction, plus you put the unlikely case inside the if conditional.

I'm inclined to do the latter and just flip the sense of the "if" since
I already scratched my head trying to think of a good name (and
apparently failed in the end).

Thanks,
Paul.

> 
> Neil
> 

      reply	other threads:[~2012-12-07 19:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 14:28 [PATCH net-next 00/10] tipc: more updates for the v3.8 content Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 01/10] tipc: remove obsolete flush of stale reassembly buffer Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 02/10] tipc: eliminate aggregate sk_receive_queue limit Paul Gortmaker
2012-12-07 16:07   ` Neil Horman
2012-12-07 17:36     ` David Miller
2012-12-07 19:54       ` Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 03/10] tipc: sk_recv_queue size check only for connectionless sockets Paul Gortmaker
2012-12-07 19:20   ` Neil Horman
2012-12-07 22:30     ` Jon Maloy
2012-12-09 16:50       ` Neil Horman
2012-12-10  6:27         ` Ying Xue
2012-12-10  8:46           ` Jon Maloy
2012-12-10 14:22           ` Neil Horman
2012-12-07 14:28 ` [PATCH net-next 04/10] tipc: change sk_receive_queue upper limit Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 05/10] tipc: standardize across connect/disconnect function naming Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 06/10] tipc: consolidate connection-oriented message reception in one function Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 07/10] tipc: introduce non-blocking socket connect Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 08/10] tipc: eliminate connection setup for implied connect in recv_msg() Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 09/10] tipc: add lock nesting notation to quiet lockdep warning Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 10/10] tipc: refactor accept() code for improved readability Paul Gortmaker
2012-12-07 19:42   ` Neil Horman
2012-12-07 19:56     ` Paul Gortmaker [this message]

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=20121207195629.GB27639@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=davem@davemloft.net \
    --cc=jon.maloy@ericsson.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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.