1. 04 10月, 2008 1 次提交
    • C
      lockd: Remove unused fields in the nlm_reboot structure · 9a38a838
      Chuck Lever 提交于
      The nlm_reboot structure is used to store information provided by the
      NSM_NOTIFY procedure.  This procedure is not specified by the NLM or NSM
      protocols, other than to say that the procedure can be used to transmit
      information private to a particular NLM/NSM implementation.
      
      For Linux, the callback arguments include the name of the monitored host,
      the new NSM state of the host, and a 16-byte private opaque.
      
      As a clean up, remove the unused fields and the server-side XDR logic that
      decodes them.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      9a38a838
  2. 02 2月, 2008 1 次提交
  3. 14 12月, 2006 1 次提交
  4. 21 10月, 2006 1 次提交
  5. 17 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: Allow lockd to drop replies as appropriate · d343fce1
      NeilBrown 提交于
      It is possible for the ->fopen callback from lockd into nfsd to find that an
      answer cannot be given straight away (an upcall is needed) and so the request
      has to be 'dropped', to be retried later.  That error status is not currently
      propagated back.
      
      So:
        Change nlm_fopen to return nlm error codes (rather than a private
        protocol) and define a new nlm_drop_reply code.
        Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply
        when this error comes back.
        Cause svc_process to drop a request which returns a status of
        rpc_drop_reply.
      
      [akpm@osdl.org: fix warning storm]
      Cc: Marc Eshel <eshel@almaden.ibm.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d343fce1
  6. 21 3月, 2006 1 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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