1. 18 10月, 2007 1 次提交
  2. 11 10月, 2007 2 次提交
  3. 03 5月, 2007 1 次提交
    • J
      [PATCH] i386: Convert PDA into the percpu section · 7c3576d2
      Jeremy Fitzhardinge 提交于
      Currently x86 (similar to x84-64) has a special per-cpu structure
      called "i386_pda" which can be easily and efficiently referenced via
      the %fs register.  An ELF section is more flexible than a structure,
      allowing any piece of code to use this area.  Indeed, such a section
      already exists: the per-cpu area.
      
      So this patch:
      (1) Removes the PDA and uses per-cpu variables for each current member.
      (2) Replaces the __KERNEL_PDA segment with __KERNEL_PERCPU.
      (3) Creates a per-cpu mirror of __per_cpu_offset called this_cpu_off, which
          can be used to calculate addresses for this CPU's variables.
      (4) Simplifies startup, because %fs doesn't need to be loaded with a
          special segment at early boot; it can be deferred until the first
          percpu area is allocated (or never for UP).
      
      The result is less code and one less x86-specific concept.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      7c3576d2
  4. 17 3月, 2007 1 次提交
  5. 01 7月, 2006 1 次提交
  6. 11 4月, 2006 1 次提交
  7. 25 2月, 2006 1 次提交
    • J
      [PATCH] x86: fix broken SMP boot sequence · 2b932f6c
      James Bottomley 提交于
      Recent GDT changes broke the SMP boot sequence if the booting CPU is
      numbered anything other than zero.  There's also a subtle source of error
      in that the boot time CPU now uses cpu_gdt_table (which is actually the GDT
      for booting CPUs in head.S).  This patch fixes both problems by making GDT
      descriptors themselves allocated from a per_cpu area and switching to them
      in cpu_init(), which now means that cpu_gdt_table is exclusively used for
      booting CPUs again.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      Cc: Zachary Amsden <zach@vmware.com>
      Cc: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2b932f6c
  8. 07 1月, 2006 1 次提交
  9. 24 6月, 2005 1 次提交
  10. 06 5月, 2005 1 次提交
    • P
      [PATCH] x86_64: make string func definition work as intended · 0c28130b
      Paolo 'Blaisorblade' Giarrusso 提交于
      In include/asm-x86_64/string.h there are such comments:
      
      /* Use C out of line version for memcmp */
      #define memcmp __builtin_memcmp
      int memcmp(const void * cs,const void * ct,size_t count);
      
      This would mean that if the compiler does not decide to use __builtin_memcmp,
      it emits a call to memcmp to be satisfied by the C out-of-line version in
      lib/string.c.  What happens is that after preprocessing, in lib/string.i you
      may find the definition of "__builtin_strcmp".
      
      Actually, by accident, in the object you will find the definition of strcmp
      and such (maybe a trick intended to redirect calls to __builtin_memcmp to the
      default memcmp when the definition is not expanded); however, this particular
      case is not a documented feature as far as I can see.
      
      Also, the EXPORT_SYMBOL does not work, so it's duplicated in the arch.
      
      I simply added some #undef to lib/string.c and removed the (now duplicated)
      exports in x86-64 and UML/x86_64 subarchs (the second ones are introduced by
      another patch I just posted for -mm).
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      CC: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c28130b
  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