1. 15 Jul, 2011 1 commit
  2. 09 Aug, 2009 1 commit
    • Chuck Lever's avatar
      SUNRPC: Provide functions for managing universal addresses · a02d6926
      Chuck Lever authored
      
      Introduce a set of functions in the kernel's RPC implementation for
      converting between a socket address and either a standard
      presentation address string or an RPC universal address.
      
      The universal address functions will be used to encode and decode
      RPCB_FOO and NFSv4 SETCLIENTID arguments.  The other functions are
      part of a previous promise to deliver shared functions that can be
      used by upper-layer protocols to display and manipulate IP
      addresses.
      
      The kernel's current address printf formatters were designed
      specifically for kernel to user-space APIs that require a particular
      string format for socket addresses, thus are somewhat limited for the
      purposes of sunrpc.ko.  The formatter for IPv6 addresses, %pI6, does
      not support short-handing or scope IDs.  Also, these printf formatters
      are unique per address family, so a separate formatter string is
      required for printing AF_INET and AF_INET6 addresses.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      a02d6926
  3. 17 Jun, 2009 2 commits
    • Ricardo Labiaga's avatar
      nfs41: Backchannel callback service helper routines · 0d90ba1c
      Ricardo Labiaga authored
      
      Executes the backchannel task on the RPC state machine using
      the existing open connection previously established by the client.
      Signed-off-by: default avatarRicardo Labiaga <ricardo.labiaga@netapp.com>
      
      nfs41: Add bc_svc.o to sunrpc Makefile.
      
      [nfs41: bc_send() does not need to be exported outside RPC module]
      [nfs41: xprt_free_bc_request() need not be exported outside RPC module]
      Signed-off-by: default avatarRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      [Update copyright]
      Signed-off-by: default avatarRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      0d90ba1c
    • Ricardo Labiaga's avatar
      nfs41: New backchannel helper routines · fb7a0b9a
      Ricardo Labiaga authored
      
      This patch introduces support to setup the callback xprt on the client side.
      It allocates/ destroys the preallocated memory structures used to process
      backchannel requests.
      
      At setup time, xprt_setup_backchannel() is invoked to allocate one or
      more rpc_rqst structures and substructures.  This ensures that they
      are available when an RPC callback arrives.  The rpc_rqst structures
      are maintained in a linked list attached to the rpc_xprt structure.
      We keep track of the number of allocations so that they can be correctly
      removed when the channel is destroyed.
      
      When an RPC callback arrives, xprt_alloc_bc_request() is invoked to
      obtain a preallocated rpc_rqst structure.  An rpc_xprt structure is
      returned, and its RPC_BC_PREALLOC_IN_USE bit is set in
      rpc_xprt->bc_flags.  The structure is removed from the the list
      since it is now in use, and it will be later added back when its
      user is done with it.
      
      After the RPC callback replies, the rpc_rqst structure is returned
      by invoking xprt_free_bc_request().  This clears the
      RPC_BC_PREALLOC_IN_USE bit and adds it back to the list, allowing it
      to be reused by a subsequent RPC callback request.
      
      To be consistent with the reception of RPC messages, the backchannel requests
      should be placed into the 'struct rpc_rqst' rq_rcv_buf, which is then in turn
      copied to the 'struct rpc_rqst' rq_private_buf.
      
      [nfs41: Preallocate rpc_rqst receive buffer for handling callbacks]
      Signed-off-by: default avatarRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      [Update copyright notice and explain page allocation]
      Signed-off-by: default avatarRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      fb7a0b9a
  4. 14 Mar, 2008 1 commit
  5. 01 Feb, 2008 1 commit
    • Tom Tucker's avatar
      svc: Add an svc transport class · 1d8206b9
      Tom Tucker authored
      
      The transport class (svc_xprt_class) represents a type of transport, e.g.
      udp, tcp, rdma.  A transport class has a unique name and a set of transport
      operations kept in the svc_xprt_ops structure.
      
      A transport class can be dynamically registered and unregisterd. The
      svc_xprt_class represents the module that implements the transport
      type and keeps reference counts on the module to avoid unloading while
      there are active users.
      
      The endpoint (svc_xprt) is a generic, transport independent endpoint that can
      be used to send and receive data for an RPC service. It inherits it's
      operations from the transport class.
      
      A transport driver module registers and unregisters itself with svc sunrpc
      by calling svc_reg_xprt_class, and svc_unreg_xprt_class respectively.
      Signed-off-by: default avatarTom Tucker <tom@opengridcomputing.com>
      Acked-by: default avatarNeil Brown <neilb@suse.de>
      Reviewed-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarGreg Banks <gnb@sgi.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      1d8206b9
  6. 09 Oct, 2007 1 commit
  7. 01 May, 2007 2 commits
  8. 23 Sep, 2005 2 commits
  9. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4