compression plugin compress level validation

Ferenc Wágner wferi at
Fri Feb 9 17:01:12 CET 2018

"Fabio M. Di Nitto" <fdinitto at> writes:

> AFAIR all plugins accept an int value for compress_level so from that
> perspective it shouldn´t be too much of a problem (aka no API/ABI changes).

The plugins do accept an integer compress level because that's what they
get from libknet.  And this is a good fit for most, but requires an
arbitrary mapping for lzo2, which has no concept of compress level, only
different compression algorithms, directly selectable by the user.

> I think Feri´s suggestion to drop the filter completely might be too
> much, instead, after thinking a bit, it might be perfectly reason to
> change the internals of val_level to try and compress a small buffer to
> test that the value is good.
> The val_level is used only at configuration time, so it´s not too
> expensive to compress one small data chunk for validation and it would
> remove the whole hardcoded filter of different compress_levels.

While I can imagine it work, it still somehow feels conceptually
backwards to me.  What if we let a "bad" value through?  The first send
will fail, I guess.  Is that really worse than filtering during

> For special plugins like lzo2, I think it´s important we improve the
> logging at configuration time to make sure users at least warned of
> supported values (as you can see each values map to a specific lzo2 API
> call to compress).

It's easy to do and maintain and saves a round trip to the fine
documentation, so why not?

More information about the Devel mailing list