1. 17 10月, 2007 1 次提交
    • J
      uml: throw out CONFIG_MODE_TT · 42fda663
      Jeff Dike 提交于
      This patchset throws out tt mode, which has been non-functional for a while.
      
      This is done in phases, interspersed with code cleanups on the affected files.
      
      The removal is done as follows:
      	remove all code, config options, and files which depend on
      CONFIG_MODE_TT
      	get rid of the CHOOSE_MODE macro, which decided whether to
      call tt-mode or skas-mode code, and replace invocations with their
      skas portions
      	replace all now-trivial procedures with their skas equivalents
      
      There are now a bunch of now-redundant pieces of data structures, including
      mode-specific pieces of the thread structure, pt_regs, and mm_context.  These
      are all replaced with their skas-specific contents.
      
      As part of the ongoing style compliance project, I made a style pass over all
      files that were changed.  There are three such patches, one for each phase,
      covering the files affected by that phase but no later ones.
      
      I noticed that we weren't freeing the LDT state associated with a process when
      it exited, so that's fixed in one of the later patches.
      
      The last patch is a tidying patch which I've had for a while, but which caused
      inexplicable crashes under tt mode.  Since that is no longer a problem, this
      can now go in.
      
      This patch:
      
      Start getting rid of tt mode support.
      
      This patch throws out CONFIG_MODE_TT and all config options, code, and files
      which depend on it.
      
      CONFIG_MODE_SKAS is gone and everything that depends on it is included
      unconditionally.
      
      The few changed lines are in re-written Kconfig help, lines which needed
      something skas-related removed from them, and a few more which weren't
      strictly deletions.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42fda663
  2. 27 9月, 2006 1 次提交
    • J
      [PATCH] uml: thread creation tidying · 3c917350
      Jeff Dike 提交于
      fork on UML has always somewhat subtle.  The underlying cause has been the
      need to initialize a stack for the new process.  The only portable way to
      initialize a new stack is to set it as the alternate signal stack and take a
      signal.  The signal handler does whatever initialization is needed and jumps
      back to the original stack, where the fork processing is finished.  The basic
      context switching mechanism is a jmp_buf for each process.  You switch to a
      new process by longjmping to its jmp_buf.
      
      Now that UML has its own implementation of setjmp and longjmp, and I can poke
      around inside a jmp_buf without fear that libc will change the structure, a
      much simpler mechanism is possible.  The jmpbuf can simply be initialized by
      hand.
      
      This eliminates -
      	the need to set up and remove the alternate signal stack
      	sending and handling a signal
      	the signal blocking needed around the stack switching, since
      there is no stack switching
      	setting up the jmp_buf needed to jump back to the original
      stack after the new one is set up
      
      In addition, since jmp_buf is now defined by UML, and not by libc, it can be
      embedded in the thread struct.  This makes it unnecessary to have it exist on
      the stack, where it used to be.  It also simplifies interfaces, since the
      switch jmp_buf used to be a void * inside the thread struct, and functions
      which took it as an argument needed to define a jmp_buf variable and assign it
      from the void *.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c917350
  3. 26 9月, 2006 1 次提交
    • J
      [PATCH] uml: stack usage reduction · 75e29b18
      Jeff Dike 提交于
      The KSTK_* macros used an inordinate amount of stack.  In order to overcome
      an impedance mismatch between their interface, which just returns a single
      register value, and the interface of get_thread_regs, which took a full
      pt_regs, the implementation created an on-stack pt_regs, filled it in, and
      returned one field.  do_task_stat calls KSTK_* twice, resulting in two
      local pt_regs, blowing out the stack.
      
      This patch changes the interface (and name) of get_thread_regs to just
      return a single register from a jmp_buf.
      
      The include of archsetjmp.h" in registers.h to get the definition of
      jmp_buf exposed a bogus include of <setjmp.h> in start_up.c.  <setjmp.h>
      shouldn't be used anywhere any more since UML uses the klibc
      setjmp/longjmp.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      75e29b18
  4. 26 4月, 2006 1 次提交
  5. 11 1月, 2006 1 次提交
  6. 05 10月, 2005 1 次提交
  7. 18 9月, 2005 1 次提交
    • J
      [PATCH] uml: breakpoint an arbitrary thread · 3eddddcf
      Jeff Dike 提交于
      This patch implements a stack trace for a thread, not unlike sysrq-t does.
      The advantage to this is that a break point can be placed on showreqs, so that
      upon showing the stack, you jump immediately into the debugger.  While sysrq-t
      does the same thing, sysrq-t shows *all* threads stacks.  It also doesn't work
      right now.  In the future, I thought it might be acceptable to make this show
      all pids stacks, but perhaps leaving well enough alone and just using sysrq-t
      would be okay.  For now, upon receiving the stack command, UML switches
      context to that thread, dumps its registers, and then switches context back to
      the original thread.  Since UML compacts all threads into one of 4 host
      threads, this sort of mechanism could be expanded in the future to include
      other debugging helpers that sysrq does not cover.
      
      Note by jdike - The main benefit to this is that it brings an arbitrary thread
      back into context, where it can be examined by gdb.  The fact that it dumps it
      stack is secondary.  This provides the capability to examine a sleeping
      thread, which has existed in tt mode, but not in skas mode until now.
      
      Also, the other threads, that sysrq doesn't cover, can be gdb-ed directly
      anyway.
      
      Signed-off-by: Allan Graves<allan.graves@gmail.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3eddddcf
  8. 06 5月, 2005 1 次提交
    • B
      [PATCH] uml: S390 preparation, abstract host page fault data · c578455a
      Bodo Stroesser 提交于
      This patch removes the arch-specific fault/trap-infos from thread and
      skas-regs.
      
      It adds a new struct faultinfo, that is arch-specific defined in
      sysdep/faultinfo.h.
      
      The structure is inserted in thread.arch and thread.regs.skas and
      thread.regs.tt
      
      Now, segv and other trap-handlers can copy the contents from regs.X.faultinfo
      to thread.arch.faultinfo with one simple assignment.
      
      Also, the number of macros necessary is reduced to
      
      FAULT_ADDRESS(struct faultinfo)
          extracts the faulting address from faultinfo
      
      FAULT_WRITE(struct faultinfo)
          extracts the "is_write" flag
      
      SEGV_IS_FIXABLE(struct faultinfo)
          is true for the fixable segvs, i.e. (TRAP == 14)
          on i386
      
      UPT_FAULTINFO(regs)
          result is (struct faultinfo *) to the faultinfo
          in regs->skas.faultinfo
      
      GET_FAULTINFO_FROM_SC(struct faultinfo, struct sigcontext *)
          copies the relevant parts of the sigcontext to
          struct faultinfo.
      
      On SIGSEGV, call user_signal() instead of handle_segv(), if the architecture
      provides the information needed in PTRACE_FAULTINFO, or if PTRACE_FAULTINFO is
      missing, because segv-stub will provide the info.
      
      The benefit of the change is, that in case of a non-fixable SIGSEGV, we can
      give user processes a SIGSEGV, instead of possibly looping on pagefault
      handling.
      
      Since handle_segv() sikked arch_fixup() implicitly by passing ip==0 to segv(),
      I changed segv() to call arch_fixup() only, if !is_user.
      Signed-off-by: NBodo Stroesser <bstroesser@fujitsu-siemens.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c578455a
  9. 01 5月, 2005 2 次提交
  10. 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