Re: [PATCH][2/2] SquashFS

[Phillip Lougher]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/