GEOM_ULZMA

[Ivan Voras]

On 02/19/10 15:36, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in connection with this is an issue best left lzma

One of the (relatively) unexpected problems with such block-level 
compression is its efficienty - since you need to compress individual 
blocks to be seekable (if you are not designing a special algorithm), 
the compression ratios tend to not increase in a big way as the 
algorithm improves. It would be interesting to see a comparison of sizes 
with geom_uzip if you have them.

 > code in the file "geom_ulzma.c" or store lzma library separately. If 
separately, then where better?

The code organization depends on what you want to do with it and how you 
want to update the code in the future, if your lzma library is third party.

If you never intend to update the lzma code then I guess it's fine to 
embed it in a big .c file. For a port, it doesn't matter much since it 
is your own thing. There are stricter rules on maintainability and style 
if you want it in the base system.

> Maybe in future make lzma and gzip library kernel interface for embedded?
> Then in one instance of code, userland can use compression via kernel.

This never happens now (I mean userland calling into the kernel for 
compression) so you will need to explain the benefits first (kernel code 
is not magically faster than userland - it runs on the same CPU).