1. 23 3月, 2011 2 次提交
    • S
      adfs: add hexadecimal filetype suffix option · da23ef05
      Stuart Swales 提交于
      ADFS (FileCore) storage complies with the RISC OS filetype specification
      (12 bits of file type information is stored in the file load address,
      rather than using a file extension).  The existing driver largely ignores
      this information and does not present it to the end user.
      
      It is desirable that stored filetypes be made visible to the end user to
      facilitate a precise copy of data and metadata from a hard disc (or image
      thereof) into a RISC OS emulator (such as RPCEmu) or to a network share
      which can be accessed by real Acorn systems.
      
      This patch implements a per-mount filetype suffix option (use -o
      ftsuffix=1) to present any filetype as a ,xyz hexadecimal suffix on each
      file.  This type suffix is compatible with that used by RISC OS systems
      that access network servers using NFS client software and by RPCemu's host
      filing system.
      Signed-off-by: NStuart Swales <stuart.swales.croftnuisk@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da23ef05
    • S
      adfs: fix E+/F+ dir size > 2048 crashing kernel · 2f09719a
      Stuart Swales 提交于
      Kernel crashes in fs/adfs module when accessing directories with a large
      number of objects on mounted Acorn ADFS E+/F+ format discs (or images) as
      the existing code writes off the end of the fixed array of struct
      buffer_head pointers.
      
      Additionally, each directory access that didn't crash would leak a buffer
      as nr_buffers was not adjusted correctly for E+/F+ discs (was always left
      as one less than required).
      
      The patch fixes this by allocating a dynamically-sized set of struct
      buffer_head pointers if necessary for the E+/F+ case (many directories
      still do in fact fit in 2048 bytes) and sets the correct nr_buffers so
      that all buffers are released.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=26072
      
      Tested by tar'ing the contents of my RISC PC's E+ format 20Gb HDD which
      contains a number of large directories that previously crashed the kernel.
      Signed-off-by: NStuart Swales <stuart.swales.croftnuisk@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f09719a
  2. 06 3月, 2010 1 次提交
  3. 17 6月, 2009 1 次提交
  4. 12 6月, 2009 1 次提交
  5. 28 3月, 2009 1 次提交
  6. 30 4月, 2008 1 次提交
  7. 13 2月, 2007 1 次提交
  8. 29 3月, 2006 1 次提交
  9. 09 11月, 2005 1 次提交
    • O
      [PATCH] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason · 733482e4
      Olaf Hering 提交于
      This patch removes almost all inclusions of linux/version.h.  The 3
      #defines are unused in most of the touched files.
      
      A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
      unfortunatly in linux/version.h.
      
      There are also lots of #ifdef for long obsolete kernels, this was not
      touched.  In a few places, the linux/version.h include was move to where
      the LINUX_VERSION_CODE was used.
      
      quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`
      
      search pattern:
      /UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      733482e4
  10. 21 8月, 2005 1 次提交
  11. 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