1. 17 8月, 2005 1 次提交
  2. 11 7月, 2005 1 次提交
  3. 21 6月, 2005 1 次提交
  4. 09 6月, 2005 1 次提交
  5. 08 6月, 2005 1 次提交
  6. 13 5月, 2005 1 次提交
  7. 11 5月, 2005 1 次提交
  8. 06 5月, 2005 1 次提交
  9. 04 5月, 2005 1 次提交
  10. 30 4月, 2005 1 次提交
    • N
      [PATCH] ARM: 2651/3: kernel helpers for NPTL support · 2d2669b6
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      This patch entirely reworks the kernel assistance for NPTL on ARM.
      In particular this provides an efficient way to retrieve the TLS
      value and perform atomic operations without any instruction emulation
      nor special system call.  This even allows for pre ARMv6 binaries to
      be forward compatible with SMP systems without any penalty.
      The problematic and performance critical operations are performed
      through segment of kernel provided user code reachable from user space
      at a fixed address in kernel memory.  Those fixed entry points are
      within the vector page so we basically get it for free as no extra
      memory page is required and nothing else may be mapped at that
      location anyway.
      This is different from (but doesn't preclude) a full blown VDSO
      implementation, however a VDSO would prevent some assembly tricks with
      constants that allows for efficient branching to those code segments.
      And since those code segments only use a few cycles before returning to
      user code, the overhead of a VDSO far call would add a significant
      overhead to such minimalistic operations.
      The ARM_NR_set_tls syscall also changed number.  This is done for two
      reasons:
      1) this patch changes the way the TLS value was previously meant to be
         retrieved, therefore we ensure whatever library using the old way
         gets fixed (they only exist in private tree at the moment since the
         NPTL work is still progressing).
      2) the previous number was allocated in a range causing an undefined
         instruction trap on kernels not supporting that syscall and it was
         determined that allocating it in a range returning -ENOSYS would be
         much nicer for libraries trying to determine if the feature is
         present or not.
      
      Signed-off-by: Nicolas Pitre
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2d2669b6
  11. 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