Add the glue code, and also update the documentation.
Signed-off-by: Phillip Lougher
---
Documentation/filesystems/squashfs.txt |8
fs/squashfs/Kconfig| 15 +++
fs/squashfs/Makefile |1 +
fs/squashfs/decompressor.c
Add the glue code, and also update the documentation.
Signed-off-by: Phillip Lougher
---
Documentation/filesystems/squashfs.txt |8
fs/squashfs/Kconfig| 15 +++
fs/squashfs/Makefile |1 +
fs/squashfs/decompressor.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3
> the journalling job also?
Ext2 does not do journaling. Ext3 does.
>> Perhaps squashfs is good enough improvement over cramfs... But I'd
>> like those 4Gb limits to go away.
>>
Pavel Machek wrote:
-snip-
So we are replacing severely-limited cramfs with also-limited
squashfs...
I think that's rather unfair, Squashfs is significantly better than
cramfs. The main aim of Squashfs has been to achieve the best
Yes, it *is* rather unfair. Sorry about that. But ha
Hi!
> Well, probably Phillip can answer this better than me, but the main
> differences that affect end users (and that is why we are using
> SquashFS right now) are:
> CRAMFS SquashFS
>
> Max File Size 16Mb 4
Hi!
[I'm not sure if I should further feed the trolls.]
> >Yes, it *is* rather unfair. Sorry about that. But having 2 different
> >limited compressed filesystems in kernel does not seem good to me.
> what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3
> the journalling job als
It is not so much selling, in my view, as putting in context.
If one can simply explain to others what is before them, so
that they can quickly understand its purposes, scope, architecture,
limitations, alternatives, and such, then others can quickly
evaluate what it is, and whether such seems lik
Hi Pavel,
On Mon, Mar 21, 2005 at 08:00:44PM +0100, Pavel Machek wrote:
> Perhaps squashfs is good enough improvement over cramfs... But I'd
> like those 4Gb limits to go away.
Well, squashfs is an *excellent* filesystem with very high compression ratios
and high speed on slow I/O devices such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
> 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.
I've only also been reading this thread with half an eye but :
Would it be possible (in some logical tim
Pavel Machek wrote:
And people merging xfs/reiserfs4/etc did address problems pointed out
in their code.
Where did I say I wasn't addressing the problems pointed out in the
code. All the issues I can fix I am addressing.
Pavel
-
To
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
Andrew Morton wrote:
Josh Boyer <[EMAIL PROTECTED]> wrote:
This is a useful, stable, and _maintained_ filesystem and I'm a bit
surprised that there is this much resistance to it's inclusion.
Although I've only been following things with half an eye, I don't think
there's a lot of resistance. It's
Josh Boyer <[EMAIL PROTECTED]> wrote:
>
> This is a useful, stable, and _maintained_ filesystem and I'm a bit
> surprised that there is this much resistance to it's inclusion.
Although I've only been following things with half an eye, I don't think
there's a lot of resistance. It's just that squ
llip Lougher <[EMAIL PROTECTED]>,
Paulo Marques <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
On Mon, 2005-03-21 at 23:49 +0100, Pavel Machek wrote:
Hi!
Perhaps squashfs is good enough
On Mon, 2005-03-21 at 23:49 +0100, 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
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'
Pavel Machek wrote:
Hi!
[I'm not sure if I should further feed the trolls.]
Yes, it *is* rather unfair. Sorry about that. But having 2 different
limited compressed filesystems in kernel does not seem good to me.
what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3
the
Hi!
> >I should have added a smiley.
> >
> >I'm not seriously suggesting that it contains deliberate problem. But
> >codestyle uglyness and arbitrary limits may come back and haunt us in
> >future. Once code is in kernel, it is very hard to change on-disk
> >format, for example.
> >
> yes, i agree
Pavel Machek wrote:
Hi,
-snip-
but if there is a contribution from the outside - it is not taken "as is"
and maybe fixed up, which
should be nearly possible in the same time like analysing and commenting
the code - it ends up
in having less supported hardware.
imho if a hardware company does in
Pavel Machek wrote:
Hi!
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.
Well, probably Phi
Pavel Machek wrote:
Well, out-of-tree maintainenance takes lot of time, too, so by keeping
limited code out-of-kernel we provide quite good incentive to make
those limits go away.
Sorry but I'm not calling Squashfs "limited" and I don't think it is.
If you wanted to nit-pick many of the current fi
Hi!
> >>>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.
> >>
> >>Well, probably Phillip
Hi!
> > > >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.
> > >
> > > Well, prob
hi everybody, hi pavel
>On Monday 21 March 2005 11:14, you wrote:
> Hi!
>
> > >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 appropria
Pavel Machek wrote:
Hi!
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.
Well, probably Phillip can answ
Hi!
> >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.
>
> Well, probably Phillip can answer
On Tue, Mar 15, 2005 at 05:04:32PM -0800, Matt Mackall wrote:
> On Tue, Mar 15, 2005 at 11:25:07PM +, Phillip Lougher wrote:
> > >>+ unsigned ints_major:16;
> > >>+ unsigned ints_minor:16;
> > >
> > >What's going on here? s_minor's not big enough for modern minor
> > >nu
On Tue, Mar 15, 2005 at 11:25:07PM +, Phillip Lougher wrote:
> Matt Mackall wrote:
> >
> >>+config SQUASHFS_1_0_COMPATIBILITY
> >>+ bool "Include support for mounting SquashFS 1.x filesystems"
> >
> >How common are these? It would be nice not to bring in legacy code.
>
> Squashfs 1.x filesys
Phillip Lougher <[EMAIL PROTECTED]> wrote:
>
> >>+ unsigned ints_major:16;
> >>+ unsigned ints_minor:16;
> >
> >
> > What's going on here? s_minor's not big enough for modern minor
> > numbers.
> >
>
> What is the modern size then?
10 bits of major, 20 bits of
Matt Mackall wrote:
On Mon, Mar 14, 2005 at 04:30:33PM +, Phillip Lougher wrote:
+config SQUASHFS_1_0_COMPATIBILITY
+ bool "Include support for mounting SquashFS 1.x filesystems"
How common are these? It would be nice not to bring in legacy code.
Squashfs 1.x filesystems were the previo
Andrew Morton wrote:
Phillip Lougher <[EMAIL PROTECTED]> 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 t
Andrew Morton wrote:
[...]
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.
Well, probably Phillip can an
On Mon, Mar 14, 2005 at 04:30:33PM +, Phillip Lougher wrote:
> +typedef unsigned int squashfs_block;
> +typedef long longsquashfs_inode;
Try using u32 and u64 instead.
> +typedef unsigned int squashfs_uid;
Why is this a typedef?
> +
> +typedef struct squashfs_sup
On Mon, Mar 14, 2005 at 04:30:33PM +, Phillip Lougher wrote:
> +config SQUASHFS_1_0_COMPATIBILITY
> + bool "Include support for mounting SquashFS 1.x filesystems"
How common are these? It would be nice not to bring in legacy code.
> +#define SERROR(s, args...) do { \
> +
Phillip Lougher <[EMAIL PROTECTED]> 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 exp
On Tuesday, March 15, 2005, at 01:06 am, Andrew Morton wrote:
Phillip Lougher <[EMAIL PROTECTED]> wrote:
@@ -0,0 +1,439 @@
[lots of comments from patch 1/2 are applicable here]
OK. Noted :-)
+#define SQUASHFS_MAX_FILE_SIZE ((long long) 1 << \
+ (SQUAS
Phillip Lougher <[EMAIL PROTECTED]> wrote:
>
>
Please don't send multiple patches with the same Subject:. Choose nice,
meaningful Subject:s for each patch. And include the relevant changelog
details within the email for each patch rather than in patch 1/N. See
http://www.zip.com.au/~akpm/linux
diff --new-file -urp linux-2.6.11.3/fs/Kconfig
linux-2.6.11.3-squashfs/fs/Kconfig
--- linux-2.6.11.3/fs/Kconfig 2005-03-13 06:44:28.0 +
+++ linux-2.6.11.3-squashfs/fs/Kconfig 2005-03-14 00:53:28.011572040 +
@@ -1170,6 +1170,45 @@ config CRAMFS
If unsure, say N.
+c
38 matches
Mail list logo
