1. 27 7月, 2011 1 次提交
  2. 23 7月, 2011 13 次提交
  3. 29 5月, 2011 2 次提交
    • M
      Blackfin: wire up new sendmmsg syscall · 427472c9
      Mike Frysinger 提交于
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      427472c9
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  4. 25 5月, 2011 9 次提交
  5. 04 5月, 2011 1 次提交
    • D
      [CPUFREQ] use dynamic debug instead of custom infrastructure · 2d06d8c4
      Dominik Brodowski 提交于
      With dynamic debug having gained the capability to report debug messages
      also during the boot process, it offers a far superior interface for
      debug messages than the custom cpufreq infrastructure. As a first step,
      remove the old cpufreq_debug_printk() function and replace it with a call
      to the generic pr_debug() function.
      
      How can dynamic debug be used on cpufreq? You need a kernel which has
      CONFIG_DYNAMIC_DEBUG enabled.
      
      To enabled debugging during runtime, mount debugfs and
      
      $ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control
      
      for debugging the complete "cpufreq" module. To achieve the same goal during
      boot, append
      
      	ddebug_query="module cpufreq +p"
      
      as a boot parameter to the kernel of your choice.
      
      For more detailled instructions, please see
      Documentation/dynamic-debug-howto.txt
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      2d06d8c4
  6. 14 4月, 2011 2 次提交
  7. 31 3月, 2011 1 次提交
  8. 29 3月, 2011 2 次提交
  9. 23 3月, 2011 1 次提交
  10. 18 3月, 2011 8 次提交
反馈
建议
客服 返回
顶部