Dave Jones wrote:
The biggest problem we've seen with it (asides from having to rediff it every time we rebase when there isn't a newer upstream)
Yes, this is mainly my fault. There was a gap of 10 months between the 3.2 release in January this year, and the latest in November. With the rate of new kernel releases this wasn't really acceptable because the January release was stuck with a patch for kernels no newer than 2.6.20. I received numerous complaints about it.
Some of you may be aware that I started work at Canonical, and this left almost no spare-time to work on Squashfs for 9 months.
is complaints along the lines of "my Fedora 7 kernel can't unpack squashfs images from Fedora 5" (s/Fedora 5/other random older distros/ )
Squashfs has backwards compatibility with older versions, and it should mount all older versions back to 2.0 (released May 2004). Unfortunately RedHat grabbed a CVS version of Squashfs just before the 3.0 release. This was development code, and release testing showed it
had a bug where it couldn't mount older versions. It was fixed for release.
If the format is now stable however, it would be great to get it upstream.
The move from the 2.0 format to the later 3.0 format was mainly forced by the demands of the Linux kernel mailing list when I first submitted it early 2005. There was no other way to incorporate demands for larger than 4GB filesystems, and provide support for "." and ".." in readdir without modifying the filesystem format.
Unfortunately the move to fixed little endian filesystem will involve another filesystem layout change. The current filesystem layout still uses packed bitfield structures, and it is impossible to swap these using the standard kernel swap macros. Removal of my routines that can properly swap packed bitfield structures is another change demanded by the Linux kernel mailing list.
Once the little endian work has been done, and hopefully once it is in the kernel, I don't anticipate any further layout changes.
Phillip - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
