Date: Mon, 14 Mar 2005 19:01:40 -0800
From: Andrew Morton <akpm@osdl.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
Message-Id: <20050314190140.5496221b.akpm@osdl.org>
In-Reply-To: <A572579D-94EF-11D9-8833-000A956F5A02@lougher.demon.co.uk>
References: <20050314170653.1ed105eb.akpm@osdl.org>
	<A572579D-94EF-11D9-8833-000A956F5A02@lougher.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1397
Lines: 31

Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
>
> [ on-disk bitfields ]
> 
> I've checked compatibilty against Intel 32 and 64 bit architectures, 
>  PPC 32/64 bit, ARM, MIPS
>  and SPARC.  I've used compilers from 2.91.x upto 3.4...

hm, OK.  I remain a bit skeptical but it sounds like you're the expert.  I
guess if things later explode it will be pretty obvious, and the filesystem
will need rework.

One thing which I assume we don't know at this stage is whether all 27
architectures work as expected - you can bet ia64 does it differently ;)

How does one test that?  Create a filesystem-in-a-file via mksquashfs, then
transfer that to a different box, then try and mount and use it, I assume?

When you upissue these patches, please include in the changelog pointers to
the relevant userspace support tools - mksquashfs, fsck.squashfs, etc.  I
guess http://squashfs.sourceforge.net/ will suit.

Also, this filesystem seems to do the same thing as cramfs.  We'd need to
understand in some detail what advantages squashfs has over cramfs to
justify merging it.  Again, that is something which is appropriate to the
changelog for patch 1/1.
-
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/