1. 11 Oct, 2006 1 commit
  2. 30 Jun, 2006 1 commit
  3. 19 Apr, 2006 1 commit
    • Hirokazu Takata's avatar
      [PATCH] m32r: Fix pt_regs for !COFNIG_ISA_DSP_LEVEL2 target · 8e8ff02c
      Hirokazu Takata authored
      
      
      This modification is required to fix debugging function for m32r targets
      with !CONFIG_ISA_DSP_LEVEL2, by unifying 'struct pt_regs' and 'struct
      sigcontext' size for all M32R ISA.
      
      Some m32r processor core with !CONFIG_ISA_DSP_LEVEL2 configuration has only
      single accumulator a0 (ex.  VDEC2 core, M32102 core, etc.), the others with
      CONFIG_ISA_DSP_LEVEL2 has two accumulators, a0 and a1.
      
      This means there are two variations of thread context.  So far, we reduced
      and changed stackframe size at a syscall for their context size.  However,
      this causes a problem that a GDB for processors with CONFIG_ISA_DSP_LEVEL2
      cannot be used for processors with !CONFIG_ISA_DSP_LEVEL2.
      
      From the viewpoint of GDB support, we should reduce such variation of
      stackframe size for simplicity.
      
      In this patch, dummy members are added to 'struct pt_regs' and 'struct
      sigcontext' to adjust their size for !CONFIG_ISA_DSP_LEVEL2.
      
      This modification is also a one step for a GDB update in future.
      Currently, on the m32r, GDB can access process's context by using ptrace
      functions in a simple way of register by register access.  By unifying
      stackframe size, we have a possibility to make use of ptrace functions of
      not only a single register access but also block register access,
      PTRACE_{GETREGS,PUTREGS}.
      
      However, for this purpose, we might have to modify stackframe structure
      some more; for example, PSW (processor status word) register should be
      pre-processed before pushing to stack at a syscall, and so on.  In this
      case, we must update carefully both kernel and GDB at a time...
      Signed-off-by: default avatarHayato Fujiwara <fujiwara@linux-m32r.org>
      Signed-off-by: default avatarHirokazu Takata <takata@linux-m32r.org>
      Cc: Kei Sakamoto <ksakamot@linux-m32r.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8e8ff02c
  4. 24 Feb, 2006 1 commit
  5. 29 Aug, 2005 1 commit
    • Steven Rostedt's avatar
      [PATCH] convert signal handling of NODEFER to act like other Unix boxes. · 69be8f18
      Steven Rostedt authored
      
      
      It has been reported that the way Linux handles NODEFER for signals is
      not consistent with the way other Unix boxes handle it.  I've written a
      program to test the behavior of how this flag affects signals and had
      several reports from people who ran this on various Unix boxes,
      confirming that Linux seems to be unique on the way this is handled.
      
      The way NODEFER affects signals on other Unix boxes is as follows:
      
      1) If NODEFER is set, other signals in sa_mask are still blocked.
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal is
      still blocked. (Note: this is the behavior of all tested but Linux _and_
      NetBSD 2.0 *).
      
      The way NODEFER affects signals on Linux:
      
      1) If NODEFER is set, other signals are _not_ blocked regardless of
      sa_mask (Even NetBSD doesn't do this).
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal being
      handled is not blocked.
      
      The patch converts signal handling in all current Linux architectures to
      the way most Unix boxes work.
      
      Unix boxes that were tested:  DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
      3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.
      
      * NetBSD was the only other Unix to behave like Linux on point #2. The
      main concern was brought up by point #1 which even NetBSD isn't like
      Linux.  So with this patch, we leave NetBSD as the lonely one that
      behaves differently here with #2.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      69be8f18
  6. 25 Jun, 2005 1 commit
    • Christoph Lameter's avatar
      [PATCH] Cleanup patch for process freezing · 3e1d1d28
      Christoph Lameter authored
      
      
      1. Establish a simple API for process freezing defined in linux/include/sched.h:
      
         frozen(process)		Check for frozen process
         freezing(process)		Check if a process is being frozen
         freeze(process)		Tell a process to freeze (go to refrigerator)
         thaw_process(process)	Restart process
         frozen_process(process)	Process is frozen now
      
      2. Remove all references to PF_FREEZE and PF_FROZEN from all
         kernel sources except sched.h
      
      3. Fix numerous locations where try_to_freeze is manually done by a driver
      
      4. Remove the argument that is no longer necessary from two function calls.
      
      5. Some whitespace cleanup
      
      6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
         cleared before setting PF_FROZEN, recalc_sigpending does not check
         PF_FROZEN).
      
      This patch does not address the problem of freeze_processes() violating the rule
      that a task may only modify its own flags by setting PF_FREEZE. This is not clean
      in an SMP environment. freeze(process) is therefore not SMP safe!
      Signed-off-by: default avatarChristoph Lameter <christoph@lameter.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3e1d1d28
  7. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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