From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/7] zram: use crypto api to check alg availability
Date: Mon, 30 May 2016 13:47:18 +0900 [thread overview]
Message-ID: <20160530044718.GC8683@bbox> (raw)
In-Reply-To: <20160529032458.GA467@swordfish>
Hi Sergey,
On Sun, May 29, 2016 at 12:24:58PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (05/27/16 18:04), Minchan Kim wrote:
> > > It is fundamentally impossible to get a list of all *potential*
> > > algorithms if you allow loadable modules. By definition someone
> > > could load a new module and thus introduce a new algorithm.
> >
> > Thanks for the quick response. I understand now.
> >
> > Sergey,
> >
> > Then, shouldn't we add functionality to load new algorithm although
> > there is no entry in zcomp backend array?
>
> can do, sure: make find_backend() depend on crypto_has_comp() only,
> *may be* printk a message when we have a mismatch in backends array
> and crypto_has_comp(). but not really sure about the latter one.
Me, too. We don't need to warn about that. Instead, we should allow loading
other algorithm which doesn't live in backend array more clearly.
We need to update documentation to clear it out.
>
> > The main reason we changed to crypto is to support various compression
> > algorithm for zram so we should be able to support anyone who want to
> > use custom crypto compression module.
>
> yes.
>
> > A idea is that let's not adding new compression string into backend
> > array from now on and deprecates /zram/comp_algorithm to show name.
>
> I'd really prefer not to deprecate /zram/comp_algorithm now.
>
> > So, from now on, users should be aware of the compression naming and
> > load module by oneself. It's not kind but I hope admins already knows
> > what cryto compressor they have.
>
> um, I'm not in love with this approach.
>
> what admins? zram users may be completely unaware of the existence of
> the crypto API and the kernel rebuild process. for some people switching
> to new zram will be a matter of "apt-get upgrade/pacman -Syu", not
> "git am ...; make menuconfig; make -j...". this looks like a major step
> back. keeping this dummy list of compressing backends around does not take
> a lot of effort, especially if we will make it unimportant for find_backend()
> and only use it for that nice user-friendly `cat /zram/comp_algorithm`
> output.
I am not against with it. Instead, please clear it out to write down docuement
"comp_algorithm is just optional so user can load any new algorithm like this
blah blah"
Thanks.
>
> -ss
next prev parent reply other threads:[~2016-05-30 4:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 14:29 [PATCH 0/7] zram: switch to crypto api Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 1/7] zram: rename zstrm find-release functions Sergey Senozhatsky
2016-05-26 0:44 ` Minchan Kim
2016-05-26 1:07 ` Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 2/7] zram: switch to crypto compress API Sergey Senozhatsky
2016-05-27 4:22 ` Minchan Kim
2016-05-27 7:59 ` Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 3/7] zram: drop zcomp param from compress/decompress Sergey Senozhatsky
2016-05-27 4:22 ` Minchan Kim
2016-05-27 7:31 ` Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 4/7] zram: align zcomp interface to crypto comp API Sergey Senozhatsky
2016-05-27 4:31 ` Minchan Kim
2016-05-27 8:00 ` Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 5/7] zram: use crypto api to check alg availability Sergey Senozhatsky
2016-05-27 4:43 ` Minchan Kim
2016-05-27 7:50 ` Sergey Senozhatsky
2016-05-27 8:27 ` Minchan Kim
2016-05-27 8:43 ` Herbert Xu
2016-05-27 9:04 ` Minchan Kim
2016-05-29 3:24 ` Sergey Senozhatsky
2016-05-30 4:47 ` Minchan Kim [this message]
2016-05-30 4:57 ` Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 6/7] zram: delete custom lzo/lz4 Sergey Senozhatsky
2016-05-25 14:30 ` [PATCH 7/7] zram: add more compression algorithms Sergey Senozhatsky
2016-05-26 0:43 ` [PATCH 0/7] zram: switch to crypto api Joonsoo Kim
2016-05-26 1:12 ` Sergey Senozhatsky
2016-05-26 1:52 ` Joonsoo Kim
2016-05-26 0:52 ` Minchan Kim
2016-05-26 1:08 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160530044718.GC8683@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).