zram-swap: default to lzo instead of lzo-rle compression

[Felix Fietkau]

On 2021-12-01 00:27, Sven Roederer wrote:
> Am Montag, 29. November 2021, 10:57:37 CET schrieb Rui Salvaterra:
>> Hi, Sven,
>> 
>> On Sun, 28 Nov 2021 at 01:40, Sven Roederer <devel-sven at geroedel.de> wrote:
>> > Rui, not sure if to call it a bug. At the end there is a hardcoded default
>> > algo in the module, that is used initially when creating the device. The
>> > check for the valid algo is done later at device-activation.
>> > I spend some time in this code and have a patch ready, which checks for
>> > algos before announcing them.
>> 
>> It's not a bug, but it's also not exactly an unsurprising behaviour.
>> This is the real issue:
>> 
>> https://elixir.bootlin.com/linux/v5.10.82/source/crypto/Makefile#L153
>> 
>> obj-$(CONFIG_CRYPTO_LZO) += lzo.o lzo-rle.o
>> 
>> Even though they're built as separate modules, they depend on a single
>> kconfig symbol. Moreover, lzo-rle uses most of the original lzo
>> functions (adding just RLE on top), so they should arguably just be
>> merged. I don't know how receptive upstream is to that idea, but it
>> seems logical to me.
>> 
> 
> Rui,
> 
> during my work I also had the impression, that both files probably share a lot
> of common code. Based on your comment I had a closer look ...
> Back in 2019 (v5.1) the linux guys explicitly split the code into separate
> files to avoid potential data-corrution.
> https://github.com/torvalds/linux/commit/45ec975efb527625629d123f305
> 
> So I don't expect joining the code again will be accepted upstream.
> 
> Back to the initial issue, I just send my patch of the selection-algorithm to
> the list for tests and comments.
> When it's proven to work, I'm fine with trying to push upstream.
Maybe upstream would accept a simple makefile change that merges both 
into a single module without changing any of the source files.

- Felix