1. 18 8月, 2008 1 次提交
  2. 19 4月, 2008 1 次提交
  3. 26 3月, 2008 1 次提交
  4. 17 10月, 2007 1 次提交
  5. 18 7月, 2007 1 次提交
    • A
      sys_fallocate() implementation on i386, x86_64 and powerpc · 97ac7350
      Amit Arora 提交于
      fallocate() is a new system call being proposed here which will allow
      applications to preallocate space to any file(s) in a file system.
      Each file system implementation that wants to use this feature will need
      to support an inode operation called ->fallocate().
      Applications can use this feature to avoid fragmentation to certain
      level and thus get faster access speed. With preallocation, applications
      also get a guarantee of space for particular file(s) - even if later the
      the system becomes full.
      
      Currently, glibc provides an interface called posix_fallocate() which
      can be used for similar cause. Though this has the advantage of working
      on all file systems, but it is quite slow (since it writes zeroes to
      each block that has to be preallocated). Without a doubt, file systems
      can do this more efficiently within the kernel, by implementing
      the proposed fallocate() system call. It is expected that
      posix_fallocate() will be modified to call this new system call first
      and incase the kernel/filesystem does not implement it, it should fall
      back to the current implementation of writing zeroes to the new blocks.
      ToDos:
      1. Implementation on other architectures (other than i386, x86_64,
         and ppc). Patches for s390(x) and ia64 are already available from
         previous posts, but it was decided that they should be added later
         once fallocate is in the mainline. Hence not including those patches
         in this take.
      2. Changes to glibc,
         a) to support fallocate() system call
         b) to make posix_fallocate() and posix_fallocate64() call fallocate()
      Signed-off-by: NAmit Arora <aarora@in.ibm.com>
      97ac7350
  6. 29 6月, 2007 1 次提交
    • D
      Introduce fixed sys_sync_file_range2() syscall, implement on PowerPC and ARM · edd5cd4a
      David Woodhouse 提交于
      Not all the world is an i386.  Many architectures need 64-bit arguments to be
      aligned in suitable pairs of registers, and the original
      sys_sync_file_range(int, loff_t, loff_t, int) was therefore wasting an
      argument register for padding after the first integer.  Since we don't
      normally have more than 6 arguments for system calls, that left no room for
      the final argument on some architectures.
      
      Fix this by introducing sys_sync_file_range2(int, int, loff_t, loff_t) which
      all fits nicely.  In fact, ARM already had that, but called it
      sys_arm_sync_file_range.  Move it to fs/sync.c and rename it, then implement
      the needed compatibility routine.  And stop the missing syscall check from
      bitching about the absence of sys_sync_file_range() if we've implemented
      sys_sync_file_range2() instead.
      
      Tested on PPC32 and with 32-bit and 64-bit userspace on PPC64.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      edd5cd4a
  7. 13 4月, 2007 1 次提交
  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. 04 12月, 2006 1 次提交
  10. 03 10月, 2006 1 次提交
    • D
      [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers · afefdbb2
      David Howells 提交于
      These patches make the kernel pass 64-bit inode numbers internally when
      communicating to userspace, even on a 32-bit system.  They are required
      because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
      for example.  The 64-bit inode numbers are then propagated to userspace
      automatically where the arch supports it.
      
      Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
      number returned by stat64() or getdents64() to differentiate files, and
      failing because the 64-bit inode number space was compressed to 32-bits, and
      so overlaps occur.
      
      This patch:
      
      Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
      inode number so that 64-bit inode numbers can be passed back to userspace.
      
      The stat functions then returns the full 64-bit inode number where
      available and where possible.  If it is not possible to represent the inode
      number supplied by the filesystem in the field provided by userspace, then
      error EOVERFLOW will be issued.
      
      Similarly, the getdents/readdir functions now pass the full 64-bit inode
      number to userspace where possible, returning EOVERFLOW instead when a
      directory entry is encountered that can't be properly represented.
      
      Note that this means that some inodes will not be stat'able on a 32-bit
      system with old libraries where they were before - but it does mean that
      there will be no ambiguity over what a 32-bit inode number refers to.
      
      Note similarly that directory scans may be cut short with an error on a
      32-bit system with old libraries where the scan would work before for the
      same reasons.
      
      It is judged unlikely that this situation will occur because modern glibc
      uses 64-bit capable versions of stat and getdents class functions
      exclusively, and that older systems are unlikely to encounter
      unrepresentable inode numbers anyway.
      
      [akpm: alpha build fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      afefdbb2
  11. 27 9月, 2006 1 次提交
  12. 01 7月, 2006 1 次提交
  13. 27 3月, 2006 2 次提交
  14. 20 2月, 2006 1 次提交
    • P
      powerpc: Keep xtime and gettimeofday in sync · 092b8f34
      Paul Mackerras 提交于
      This fixes a regression which was introduced by moving ppc32 to use
      the same sort of lockless gettimeofday as ppc64 has been using for
      some time.  This involves getting the timebase and performing some
      simple arithmetic to convert it to seconds and microseconds.  However,
      the factor and offset used there weren't being updated when NTP
      varied the tick length using adjtimex.  64-bit didn't notice the
      problem because it had a hook in the 32-bit adjtimex compat routine
      that attempted to work out what the generic timekeeping code would
      do and alter the factor and offset to match.  However, that code
      was very complex and it wasn't clear that it still matched what the
      generic code would do.
      
      Now we use the generic current_tick_length() routine that was recently
      added to check that the current tick will be as long as we expect; if
      not we recompute the factor and offset.  This keeps gettimeofday and
      xtime in sync.  In addition we check that gettimeofday hasn't got ahead
      of xtime on each timer interrupt; if it has, we resync.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      092b8f34
  15. 11 1月, 2006 1 次提交
  16. 10 1月, 2006 1 次提交
  17. 10 11月, 2005 1 次提交
  18. 18 10月, 2005 2 次提交
  19. 17 10月, 2005 1 次提交
  20. 13 10月, 2005 1 次提交
  21. 28 9月, 2005 1 次提交
  22. 09 9月, 2005 2 次提交
    • P
      Allow PCI config space syscalls to be used by 64-bit processes. · b2ad7b5e
      Paul Mackerras 提交于
      The pciconfig_iobase, pciconfig_read and pciconfig_write system calls
      were only implemented for 32-bit processes; for 64-bit processes they
      returned an ENOSYS error.  This allows them to be used by 64-bit
      processes as well.  The X server uses pciconfig_iobase at least, and
      this change is necessary to allow a 64-bit X server to work on my G5.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b2ad7b5e
    • P
      [PATCH] Separate pci bits out of struct device_node · 1635317f
      Paul Mackerras 提交于
      This patch pulls the PCI-related junk out of struct device_node and
      puts it in a separate structure, struct pci_dn.  The device_node now
      just has a void * pointer in it, which points to a struct pci_dn for
      nodes that represent PCI devices.  It could potentially be used in
      future for device-specific data for other sorts of devices, such as
      virtual I/O devices.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1635317f
  23. 08 9月, 2005 1 次提交
  24. 08 7月, 2005 2 次提交
  25. 22 6月, 2005 1 次提交
  26. 09 6月, 2005 1 次提交
    • P
      [PATCH] ppc64: Fix PER_LINUX32 behaviour · ce10d979
      Paul Mackerras 提交于
      This patch fixes some bugs in the ppc64 PER_LINUX32 implementation,
      noted by Juergen Kreileder:
      
      * uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'
      * Child processes of a PER_LINUX32 process don't inherit PER_LINUX32
      
      Along the way I took the opportunity to move things around so that
      sys_ppc32.c only has 32-bit syscall emulation functions and to remove
      the obsolete "fakeppc" command line option.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ce10d979
  27. 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