From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932662AbcE0JF6 (ORCPT ); Fri, 27 May 2016 05:05:58 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:34212 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932539AbcE0JF5 (ORCPT ); Fri, 27 May 2016 05:05:57 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.203 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 27 May 2016 18:04:38 +0900 From: Minchan Kim To: Herbert Xu CC: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Joonsoo Kim , Subject: Re: [PATCH 5/7] zram: use crypto api to check alg availability Message-ID: <20160527090438.GJ2322@bbox> References: <20160525143006.1207-1-sergey.senozhatsky@gmail.com> <20160525143006.1207-6-sergey.senozhatsky@gmail.com> <20160527044343.GE2322@bbox> <20160527075052.GB504@swordfish> <20160527082744.GH2322@bbox> <20160527084345.GA16022@gondor.apana.org.au> MIME-Version: 1.0 In-Reply-To: <20160527084345.GA16022@gondor.apana.org.au> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/05/27 18:04:16, Serialize by Router on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/05/27 18:05:53, Serialize complete at 2016/05/27 18:05:53 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 27, 2016 at 04:43:45PM +0800, Herbert Xu wrote: > On Fri, May 27, 2016 at 05:27:44PM +0900, Minchan Kim wrote: > > > > Yes, it might be trivial to adding new "string" into the backend array > > if we consider frequency of adding new compressoin algorithm in linux > > but it would be better if we can get names of supported compression > > algorithm name by crypto API. > > > > If it's not good idea or something hard to implement, let's go with > > hardcoding. > > > > Herbert, Could you give us thought? > > 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? 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. 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. 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. I don't have better idea. > > Given a specific algorithm name you could determine whether it > is present on the system. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt