RE: RFC - patch to reduce peak memory usage by disablingcompression

["Øyvind Harboe" <oyvind.harboe@zylin.com>]

>You could make it use a static buffer and serialise 
>compression, and it really would be only 4KiB you're saving.
>
>I sincerely hope this is done because you're using uncompressible 
>data, rather than trading about 4KiB of cheap RAM for a doubling 
>in expensive flash space :)
>
>If you're doing this, I'd prefer to change jffs2_compress() to 
>allocate its _own_ buffer (or optionally use a static one), 
>then have a simple definition of jffs2_compress which does 
>nothing in the !CONFIG_JFFS2_FS_COMPRESSION case. 

These are bigger changes than I want to attempt to JFFS2 at the
moment. 

>You need to handle the case where compression is configured out 
>and a filesystem created with compressed nodes is encountered -- 
>it looks like it'll die horribly at the moment.

I don't know my way around JFFS2 too well, but I thought I reported
an error in that case? 

What else can be done in this case, except to fail to read the file?

In my case, it is my own firmware that writes the JFFS2, so the
situation
will never arise. 

I can't say that I think it makes much sense to support the
configuration
of JFFS2 where it does not compress, but decompress. 

>I'd also like to see individual compression routines selectable, 
>and also at runtime with something akin to chattr.

What you describe is higher resolution of configurability, but for
my purposes the resolution is good enough.

Too many options isn't a good thing either. There will be a lot of
implied
orthogonality that isn't there(since all configurations will never be
tested).

Øyvind