• Trond Myklebust's avatar
    [PATCH] cleanup: switch to passing *(struct rpc_procinfo) in rpc_message. · 7b9edd50
    Trond Myklebust authored
    The "procedure number" has been used for 2 purposes in the kernel
    client RPC implementation:
    
      1) As a number to pass to the server in the RPC header.
    
      2) As an index into the "procedure array" of type 'struct
         rpc_procinfo', from which the RPC layer can find the XDR
         encode/decode functions, buffer size, and all the other static
         data that it needs to construct the on-wire RPC message.
    
    This works fine for NFSv2, v3 and for the NLM locking code for which
    there is a one-to-one mapping between NFS file operations, and RPC
    procedures.
    For NFSv4 on the other hand, the mapping is many-to-one, since there
    is only one RPC procedure number: NFSPROC4_COMPOUND.
    
    For efficiency purposes, we want to have a one-to-one mapping between
    NFS file operations and the corresponding XDR encode/decode routines,
    but currently this is not possible because of (2). The result is the
    mess that is 'struct nfs4_op' and encode/decode_compound.
    
    In the process eliminating (2), we might as well change to passing a
    pointer to the appropriate procedure array entry instead of an
    index. This change can be made transparent
    
    The appended patch therefore does the following:
    
       - Substitute a pointer to the rpc_procinfo instead of the RPC
         procedure number in the struct rpc_message.
       - Make the RPC procedure number an entry in the struct
         rpc_procinfo.
       - Clean out the largely unused (except in some obscure lockd
         debugging code) p_name field. The latter was just a stringified
         version of the RPC procedure name, so for those lockd cases, we
         can use the RPC procedure number instead.
    7b9edd50
unlink.c 4.84 KB