1. 15 4月, 2008 1 次提交
  2. 22 10月, 2007 1 次提交
  3. 17 10月, 2007 1 次提交
  4. 10 7月, 2007 1 次提交
  5. 25 4月, 2007 1 次提交
    • D
      [JFFS2] Tidy up licensing/copyright boilerplate. · c00c310e
      David Woodhouse 提交于
      In particular, remove the bit in the LICENCE file about contacting
      Red Hat for alternative arrangements. Their errant IS department broke
      that arrangement a long time ago -- the policy of collecting copyright
      assignments from contributors came to an end when the plug was pulled on
      the servers hosting the project, without notice or reason.
      
      We do still dual-license it for use with eCos, with the GPL+exception
      licence approved by the FSF as being GPL-compatible. It's just that nobody
      has the right to license it differently.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      c00c310e
  6. 13 2月, 2007 1 次提交
  7. 01 10月, 2006 1 次提交
  8. 29 6月, 2006 1 次提交
  9. 23 5月, 2006 1 次提交
  10. 14 5月, 2006 1 次提交
    • D
      [JFFS2] Reduce excessive node count for syslog files. · cf5eba53
      David Woodhouse 提交于
      We currently get fairly poor behaviour with files which get many short
      writes, such as system logs. This is because we end up with many tiny
      data nodes, and the rbtree gets massive. None of these nodes are
      actually obsolete, so they are counted as 'clean' space. Eraseblocks can
      be entirely full of these nodes (which are REF_NORMAL instead of
      REF_PRISTINE), and still they count entirely towards 'used_size' and the
      eraseblocks can sit on the clean_list for a long time without being
      picked for GC.
      
      One way to alleviate this in the long term is to account REF_NORMAL
      space separately from REF_PRISTINE space, rather than counting them both
      towards used_size. Then these eraseblocks can be picked for GC and the
      offending nodes will be garbage collected.
      
      The short-term fix, though -- which probably makes sense even if we do
      eventually implement the above -- is to merge these nodes as they're
      written. When we write the last byte in a page, write the _whole_ page.
      This obsoletes the earlier nodes in the page _immediately_ and we don't
      even need to wait for the garbage collection to do it.
      
      Original implementation from Ferenc Havasi <havasi@inf.u-szeged.hu>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      cf5eba53
  11. 13 5月, 2006 1 次提交
    • K
      [JFFS2][XATTR] XATTR support on JFFS2 (version. 5) · aa98d7cf
      KaiGai Kohei 提交于
      This attached patches provide xattr support including POSIX-ACL and
      SELinux support on JFFS2 (version.5).
      
      There are some significant differences from previous version posted
      at last December.
      The biggest change is addition of EBS(Erase Block Summary) support.
      Currently, both kernel and usermode utility (sumtool) can recognize
      xattr nodes which have JFFS2_NODETYPE_XATTR/_XREF nodetype.
      
      In addition, some bugs are fixed.
      - A potential race condition was fixed.
      - Unexpected fail when updating a xattr by same name/value pair was fixed.
      - A bug when removing xattr name/value pair was fixed.
      
      The fundamental structures (such as using two new nodetypes and exclusion
      mechanism by rwsem) are unchanged. But most of implementation were reviewed
      and updated if necessary.
      Espacially, we had to change several internal implementations related to
      load_xattr_datum() to avoid a potential race condition.
      
      [1/2] xattr_on_jffs2.kernel.version-5.patch
      [2/2] xattr_on_jffs2.utils.version-5.patch
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      aa98d7cf
  12. 29 3月, 2006 1 次提交
  13. 07 11月, 2005 3 次提交
  14. 08 9月, 2005 1 次提交
  15. 06 7月, 2005 1 次提交
  16. 01 5月, 2005 1 次提交
  17. 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