1. 29 3月, 2008 1 次提交
  2. 17 10月, 2007 2 次提交
    • D
      KEYS: Make request_key() and co fundamentally asynchronous · 76181c13
      David Howells 提交于
      Make request_key() and co fundamentally asynchronous to make it easier for
      NFS to make use of them.  There are now accessor functions that do
      asynchronous constructions, a wait function to wait for construction to
      complete, and a completion function for the key type to indicate completion
      of construction.
      
      Note that the construction queue is now gone.  Instead, keys under
      construction are linked in to the appropriate keyring in advance, and that
      anyone encountering one must wait for it to be complete before they can use
      it.  This is done automatically for userspace.
      
      The following auxiliary changes are also made:
      
       (1) Key type implementation stuff is split from linux/key.h into
           linux/key-type.h.
      
       (2) AF_RXRPC provides a way to allocate null rxrpc-type keys so that AFS does
           not need to call key_instantiate_and_link() directly.
      
       (3) Adjust the debugging macros so that they're -Wformat checked even if
           they are disabled, and make it so they can be enabled simply by defining
           __KDEBUG to be consistent with other code of mine.
      
       (3) Documentation.
      
      [alan@lxorguk.ukuu.org.uk: keys: missing word in documentation]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      76181c13
    • A
      fs/afs/: possible cleanups · c1206a2c
      Adrian Bunk 提交于
      This patch contains the following possible cleanups:
      - make the following needlessly global functions static:
        - rxrpc.c: afs_send_pages()
        - vlocation.c: afs_vlocation_queue_for_updates()
        - write.c: afs_writepages_region()
      - make the following needlessly global variables static:
        - mntpt.c: afs_mntpt_expiry_timeout
        - proc.c: afs_vlocation_states[]
        - server.c: afs_server_timeout
        - vlocation.c: afs_vlocation_timeout
        - vlocation.c: afs_vlocation_update_timeout
      - #if 0 the following unused function:
        - cell.c: afs_get_cell_maybe()
      - #if 0 the following unused variables:
        - callback.c: afs_vnode_update_timeout
        - cmservice.c: struct afs_cm_workqueue
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c1206a2c
  3. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  4. 27 4月, 2007 3 次提交
  5. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  6. 27 6月, 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