On (06/01/16 15:47), Minchan Kim wrote:Ideally, it should fall back to whatever algorithm it can find that is supported, preferably in the following order:
so both BUILTIN and BUILT-AS-A-MODULE cases are handled at compile
time now and we can avoid crypto_has_comp() checks for most of the
comp_algorithm calls, except for the case when someone requests an
Hmm, isn't it problem, either?
That module was built but not installed. In that case, setting the
algorithm will be failed. IOW, we are lying to user.
have you ever seen this? really, why should we even bother?
if there is no requested algorithm we will fallback to LZO.
and how is that different from: user enabled LZO in .config (because it's
a prerequisite for zram) but forgot to install the module? do we have to
"fix" this as well?... implement our own LZO compression in zram?
or `cp lib/lzo/* drivers/block/zram/'?
Just from the perspective of a system administrator, most people probably aren't going to be directly touching the sysfs entries themselves except possibly for testing, and I don't think I've ever seen anything that actually reads zram/comp_algorithm except to verify that it's set to the requested algorithm. Given that, the behavior I'd expect from zram/comp_algorithm as an administrator would be:
For solving the problem, if we check it with crypto_has_comp, again,
it will load module into memory. :(
this will require a *VERY* non-standard behaviour from user
echo 842 > /sys/block/zram0/comp_algorithm
and I'm quite confident that anyone who does this actually want
to init the device with the requested out-of-tree module right
after `echo FOO > comp_algorithm', rather than anything else.