Re: [PATCH][2/2] SquashFS

[Phillip Lougher <phillip@lougher.demon.co.uk>]

Pavel Machek wrote:
> Hi!
> 
> 
>>>Perhaps squashfs is good enough improvement over cramfs... But I'd
>>>like those 4Gb limits to go away.
>>
>>So would I.  But it is a totally groundless reason to refuse kernel 
>>submission because of that, Squashfs users are quite happily using it 
>>with such a "terrible" limitation.  I'm asking for Squashfs to be put in 
>>the kernel _now_ because users are asking me to do it _now_.  If it 
> 
> 
> Putting it into kernel because users want it is... not a good
> reason. You should put it there if it is right thing to do. I believe
> you should address those endianness issues and drop V1 support. If
> breaking 4GB limit does not involve on-disk format change, it may be
> okay to merge. After code is merged, doing format changes will be
> hard...
> 
> 								Pavel

So users don't matter anymore, now that's a terrible admission to make. 
  Linux wouldn't be where it is today without all those "mere" users.

I obviously think putting Squashfs into the kernel is the right thing to do.

The filesystem is endian safe and has been since the first release - it 
works on big endian and little endian, and every architecure I've tried 
it on it works (Intel 32/64, PowerPC 32/64. MIPS, ARM, Sparx).  The 
endian code which everyone seems to have got so worked up about is there 
to _make_ it endian safe.  I've already explained why making Squashfs 
natively support both little endian and big endian is important for 
embedded systems.

I have agreed to drop V1.0 support, and yes (as explained in another 
emauil), breaking the 4GB limit does involve on-disk format change.