From: Herbert Xu Subject: Re: comparison of the AF_ALG interface with the /dev/crypto Date: Thu, 1 Sep 2011 23:08:38 +0800 Message-ID: <20110901150838.GA31988@gondor.apana.org.au> References: <20110901133952.GB14522@orbit.nwl.cc> <20110901141445.GA31447@gondor.apana.org.au> <20110901145902.GA31834@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Phil Sutter , cryptodev-linux-devel@gna.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org To: Nikos Mavrogiannopoulos Return-path: Received: from helcar.apana.org.au ([209.40.204.226]:42486 "EHLO fornost.hengli.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932185Ab1IAPIr (ORCPT ); Thu, 1 Sep 2011 11:08:47 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: On Thu, Sep 01, 2011 at 05:06:06PM +0200, Nikos Mavrogiannopoulos wrote: > > Indeed but today that's what we have in some systems. User-space TLS > implementations (GnuTLS and OpenSSL) and kernel-space crypto > offloading. The purpose of the /dev/crypto and AF_ALG interfaces is to > connect those together. It would be interesting to have a partial > kernel-space TLS implementation but I don't know whether such a thing > could ever make it to kernel. Well we've talked about a kernel implementation of the data path previously and I don't think there is any opposition to the idea. The only thing missing is an implementation. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt