![]() | |||||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:11 [from the cache] ©2003-2008 | |||||||||||||