1. 26 8月, 2008 1 次提交
  2. 20 7月, 2008 1 次提交
  3. 20 2月, 2008 1 次提交
  4. 06 2月, 2008 1 次提交
    • D
      timerfd: new timerfd API · 4d672e7a
      Davide Libenzi 提交于
      This is the new timerfd API as it is implemented by the following patch:
      
      int timerfd_create(int clockid, int flags);
      int timerfd_settime(int ufd, int flags,
      		    const struct itimerspec *utmr,
      		    struct itimerspec *otmr);
      int timerfd_gettime(int ufd, struct itimerspec *otmr);
      
      The timerfd_create() API creates an un-programmed timerfd fd.  The "clockid"
      parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
      
      The timerfd_settime() API give new settings by the timerfd fd, by optionally
      retrieving the previous expiration time (in case the "otmr" parameter is not
      NULL).
      
      The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
      is set in the "flags" parameter.  Otherwise it's a relative time.
      
      The timerfd_gettime() API returns the next expiration time of the timer, or
      {0, 0} if the timerfd has not been set yet.
      
      Like the previous timerfd API implementation, read(2) and poll(2) are
      supported (with the same interface).  Here's a simple test program I used to
      exercise the new timerfd APIs:
      
      http://www.xmailserver.org/timerfd-test2.c
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [akpm@linux-foundation.org: fix ia64 build]
      [akpm@linux-foundation.org: fix m68k build]
      [akpm@linux-foundation.org: fix mips build]
      [akpm@linux-foundation.org: fix alpha, arm, blackfin, cris, m68k, s390, sparc and sparc64 builds]
      [heiko.carstens@de.ibm.com: fix s390]
      [akpm@linux-foundation.org: fix powerpc build]
      [akpm@linux-foundation.org: fix sparc64 more]
      Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d672e7a
  5. 29 9月, 2007 1 次提交
  6. 01 8月, 2007 1 次提交
  7. 12 6月, 2007 1 次提交
  8. 07 6月, 2007 1 次提交
  9. 07 3月, 2007 1 次提交
  10. 05 3月, 2007 2 次提交
  11. 27 2月, 2007 1 次提交
  12. 12 2月, 2007 1 次提交
    • K
      [PATCH] Common compat_sys_sysinfo · d4d23add
      Kyle McMartin 提交于
      I noticed that almost all architectures implemented exactly the same
      sys32_sysinfo...  except parisc, where a bug was to be found in handling of
      the uptime.  So let's remove a whole whack of code for fun and profit.
      Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it
      would be the best tested.
      
      This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but
      instead extracting out the common code from sys_sysinfo.
      
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d4d23add
  13. 07 2月, 2007 1 次提交
  14. 30 11月, 2006 1 次提交
  15. 31 10月, 2006 1 次提交
  16. 20 10月, 2006 2 次提交
  17. 02 10月, 2006 1 次提交
  18. 27 9月, 2006 2 次提交
  19. 14 7月, 2006 2 次提交
  20. 01 7月, 2006 1 次提交
  21. 30 6月, 2006 1 次提交
  22. 06 6月, 2006 1 次提交
  23. 19 4月, 2006 2 次提交
  24. 27 3月, 2006 1 次提交
  25. 28 2月, 2006 1 次提交
  26. 09 2月, 2006 1 次提交
  27. 01 12月, 2005 1 次提交
  28. 30 10月, 2005 6 次提交
  29. 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