1. 01 8月, 2008 1 次提交
  2. 07 5月, 2008 1 次提交
  3. 10 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. 27 7月, 2007 1 次提交
  6. 21 5月, 2007 2 次提交
  7. 19 3月, 2007 2 次提交
  8. 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
  9. 27 10月, 2006 1 次提交
  10. 05 10月, 2006 1 次提交
  11. 28 9月, 2006 1 次提交
  12. 16 5月, 2006 1 次提交
  13. 28 4月, 2006 1 次提交
  14. 27 3月, 2006 1 次提交
  15. 25 2月, 2006 1 次提交
    • U
      [PATCH] flags parameter for linkat · c04030e1
      Ulrich Drepper 提交于
      I'm currently at the POSIX meeting and one thing covered was the
      incompatibility of Linux's link() with the POSIX definition.  The name.
      Linux does not follow symlinks, POSIX requires it does.
      
      Even if somebody thinks this is a good default behavior we cannot change this
      because it would break the ABI.  But the fact remains that some application
      might want this behavior.
      
      We have one chance to help implementing this without breaking the behavior.
       For this we could use the new linkat interface which would need a new
      flags parameter.  If the new parameter is AT_SYMLINK_FOLLOW the new
      behavior could be invoked.
      
      I do not want to introduce such a patch now.  But we could add the
      parameter now, just don't use it.  The patch below would do this.  Can we
      get this late patch applied before the release more or less fixes the
      syscall API?
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c04030e1
  16. 18 2月, 2006 1 次提交
  17. 13 2月, 2006 1 次提交
  18. 12 2月, 2006 1 次提交
  19. 04 2月, 2006 1 次提交
  20. 02 2月, 2006 1 次提交
  21. 11 1月, 2006 1 次提交
  22. 02 8月, 2005 1 次提交
  23. 14 7月, 2005 1 次提交
    • M
      [PATCH] s390: fadvise hint values. · 068e1b94
      Martin Schwidefsky 提交于
      Add special case for the POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE hint
      values for s390-64.  The user space values in the s390-64 glibc headers for
      these two defines have always been 6 and 7 instead of 4 and 5.  All 64 bit
      applications therefore use the "wrong" values.  To get these applications
      working without recompiling the kernel needs to accept the "wrong" values.
      Since the values for s390-31 are 4 and 5 the compat wrapper for fadvise64
      and fadvise64_64 need to rewrite the values for 31 bit system calls.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      068e1b94
  24. 26 6月, 2005 1 次提交
  25. 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