On (22/11/03 13:09), Sergey Senozhatsky wrote: > On (22/11/03 12:05), Sergey Senozhatsky wrote: > > What is the use case for removal of a secondary algorithm? > > > > > My point is that we don't need to implement it atm but makes the > > > interface to open the possibility for future extension. > > > > > > What do you think? > > > > So, as far as I understand, we don't have reason to add remove_recomp_algo > > right now. And existing recomp_algo does not enforce any particular format, > > it can be extended. Right now we accept "$name" but can do something like > > "$name:$priority". > > Or with keywords: > > name=STRING priority=INT > > and the only legal priority for now is 1. E.g. recomp_algorithm support for algorithms name= and optional integer priority=. I sort of like the recomp_algorithm name so far, but we can change it. --- diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index cf9d3474b80c..9a614253de07 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1102,9 +1102,38 @@ static ssize_t recomp_algorithm_store(struct device *dev, size_t len) { struct zram *zram = dev_to_zram(dev); + int prio = ZRAM_SECONDARY_ZCOMP; + char *args, *param, *val; + char *alg = NULL; int ret; - ret = __comp_algorithm_store(zram, ZRAM_SECONDARY_ZCOMP, buf); + args = skip_spaces(buf); + while (*args) { + args = next_arg(args, ¶m, &val); + + if (!*val) + return -EINVAL; + + if (!strcmp(param, "name")) { + alg = val; + continue; + } + + if (!strcmp(param, "priority")) { + ret = kstrtoint(val, 10, &prio); + if (ret) + return ret; + continue; + } + } + + if (!alg) + return -EINVAL; + + if (prio < ZRAM_SECONDARY_ZCOMP || prio >= ZRAM_MAX_ZCOMPS) + return -EINVAL; + + ret = __comp_algorithm_store(zram, prio, alg); return ret ? ret : len; } #endif