[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150813073031.GC13352@js1304-P5Q-DELUXE>
Date: Thu, 13 Aug 2015 16:30:31 +0900
From: Joonsoo Kim <iamjoonsoo.kim@....com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan@...nel.org>,
Nitin Gupta <ngupta@...are.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Stephan Mueller <smueller@...onox.de>
Subject: Re: [PATCH 1/2] crypto: export crypto_alg_list and rwsem
On Thu, Aug 13, 2015 at 02:38:23PM +0800, Herbert Xu wrote:
> On Thu, Aug 13, 2015 at 03:37:55PM +0900, Joonsoo Kim wrote:
> >
> > Is there any way to access netlink interface and get the output from
> > kernel-side? I'd like to show information through
> > "/sys/block/zramX/comp_algorithm", because some user program can be
> > broken if we change output of userspace exposed interface.
>
> You could simply deprecate that interface but keep it for existing
> algorithms. Any new algorithms can then be queried through the
> crypto_user interface.
>
> The other option is to have a defined list of algorithms which is
> independent of the crypto API. For example, have a look at what
> IPsec does in net/xfrm/xfrm_algo.c. IPsec needs its own list
> because they come with annotations.
Hmm... they looks suboptimal.
How about introducing new functions to search supported algorithm in
kernel-side? As crypto API is used in more places, this interface
would be requested more. Defined list weaken the advantage of strong
point of generic crypto API.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists