• Paul Gortmaker's avatar
    tipc: standardize across connect/disconnect function naming · bc879117
    Paul Gortmaker authored
    Currently we have tipc_disconnect and tipc_disconnect_port.  It is
    not clear from the names alone, what they do or how they differ.
    It turns out that tipc_disconnect just deals with the port locking
    and then calls tipc_disconnect_port which does all the work.
    
    If we rename as follows: tipc_disconnect_port --> __tipc_disconnect
    then we will be following typical linux convention, where:
    
       __tipc_disconnect: "raw" function that does all the work.
    
       tipc_disconnect: wrapper that deals with locking and then calls
    		    the real core __tipc_disconnect function
    
    With this, the difference is immediately evident, and locking
    violations are more apt to be spotted by chance while working on,
    or even just while reading the code.
    
    On the connect side of things, we currently only have the single
    "tipc_connect2port" function.  It does both the locking at enter/exit,
    and the core of the work.  Pending changes will make it desireable to
    have the connect be a two part locking wrapper + worker function,
    just like the disconnect is already.
    
    Here, we make the connect look just like the updated disconnect case,
    for the above reason, and for consistency.  In the process, we also
    get rid of the "2port" suffix that was on the original name, since
    it adds no descriptive value.
    
    On close examination, one might notice that the above connect
    changes implicitly move the call to tipc_link_get_max_pkt() to be
    within the scope of tipc_port_lock() protected region; when it was
    not previously.  We don't see any issues with this, and it is in
    keeping with __tipc_connect doing the work and tipc_connect just
    handling the locking.
    Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
    bc879117
subscr.c 15.5 KB