1. 06 Feb, 2015 4 commits
    • Jon Paul Maloy's avatar
      tipc: split up function tipc_msg_eval() · e3a77561
      Jon Paul Maloy authored
      The function tipc_msg_eval() is in reality doing two related, but
      different tasks. First it tries to find a new destination for named
      messages, in case there was no first lookup, or if the first lookup
      failed. Second, it does what its name suggests, evaluating the validity
      of the message and its destination, and returning an appropriate error
      code depending on the result.
      
      This is confusing, and in this commit we choose to break it up into two
      functions. A new function, tipc_msg_lookup_dest(), first attempts to find
      a new destination, if the message is of the right type. If this lookup
      fails, or if the message should not be subject to a second lookup, the
      already existing tipc_msg_reverse() is called. This function performs
      prepares the message for rejection, if applicable.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3a77561
    • Jon Paul Maloy's avatar
      tipc: enqueue arrived buffers in socket in separate function · d570d864
      Jon Paul Maloy authored
      The code for enqueuing arriving buffers in the function tipc_sk_rcv()
      contains long code lines and currently goes to two indentation levels.
      As a cosmetic preparaton for the next commits, we break it out into
      a separate function.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d570d864
    • Jon Paul Maloy's avatar
      tipc: simplify message forwarding and rejection in socket layer · 1186adf7
      Jon Paul Maloy authored
      Despite recent improvements, the handling of error codes and return
      values at reception of messages in the socket layer is still confusing.
      
      In this commit, we try to make it more comprehensible. First, we
      separate between the return values coming from the functions called
      by tipc_sk_rcv(), -those are TIPC specific error codes, and the
      return values returned by tipc_sk_rcv() itself. Second, we don't
      use the returned TIPC error code as indication for whether a buffer
      should be forwarded/rejected or not; instead we use the buffer pointer
      passed along with filter_msg(). This separation is necessary because
      we sometimes want to forward messages even when there is no error
      (i.e., protocol messages and successfully secondary looked up data
      messages).
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1186adf7
    • Jon Paul Maloy's avatar
      tipc: reduce usage of context info in socket and link · c5898636
      Jon Paul Maloy authored
      The most common usage of namespace information is when we fetch the
      own node addess from the net structure. This leads to a lot of
      passing around of a parameter of type 'struct net *' between
      functions just to make them able to obtain this address.
      
      However, in many cases this is unnecessary. The own node address
      is readily available as a member of both struct tipc_sock and
      tipc_link, and can be fetched from there instead.
      The fact that the vast majority of functions in socket.c and link.c
      anyway are maintaining a pointer to their respective base structures
      makes this option even more compelling.
      
      In this commit, we introduce the inline functions tsk_own_node()
      and link_own_node() to make it easy for functions to fetch the node
      address from those structs instead of having to pass along and
      dereference the namespace struct.
      
      In particular, we make calls to the msg_xx() functions in msg.{h,c}
      context independent by directly passing them the own node address
      as parameter when needed. Those functions should be regarded as
      leaves in the code dependency tree, and it is hence desirable to
      keep them namspace unaware.
      
      Apart from a potential positive effect on cache behavior, these
      changes make it easier to introduce the changes that will follow
      later in this series.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5898636
  2. 05 Feb, 2015 36 commits