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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
