Hi:
This series introduces a new algorithm testing infrastructure
that ensures algorithms are tested where possible before they
are made available to the users.
Essentially it takes the existing tests from tcrypt and plugs
them into the registration function.
The actual mechanics is baed on
crypto: tcrypt - Add alg_test interface
This patch creates a new interface algorithm testing. A test can
be requested for a particular implementation of an algorithm. This
is achieved by taking both the name of the algorithm and that of
the implementation.
The all-inclusive test has also been
crypto: api - Use test infrastructure
This patch makes use of the new testing infrastructure by requiring
algorithms to pass a run-time test before they're made available to
users.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
---
crypto/algapi.c| 140
From Nehalem processor onward, Intel processors can support hardware
accelerated CRC32c algorithm with the new CRC32 instruction in SSE 4.2
instruction set.
The patch detects the availability of the feature, and chooses the
most proper way to calculate CRC32c checksum.
Byte code instructions
* David Woodhouse | 2008-08-04 11:12:05 [+0100]:
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
+u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
len)
+{
+ unsigned int iquotient = len / SCALE_F;
+ unsigned int iremainder = len % SCALE_F;
+#ifdef
On Mon, 2008-08-04 at 12:25 +0200, Sebastian Siewior wrote:
* David Woodhouse | 2008-08-04 11:12:05 [+0100]:
And it would be nice if we could make libcrc32c use this too, rather
than just the 'crypto' users.
I'm not sure if I remeber correctly but I thing Herbert was planning to
convert all
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
+u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
len)
+{
+ unsigned int iquotient = len / SCALE_F;
+ unsigned int iremainder = len % SCALE_F;
+#ifdef CONFIG_X86_64
+ u64 *ptmp = (u64 *)p;
+#else
On Mon, Aug 04, 2008 at 12:25:57PM +0200, Sebastian Siewior wrote:
I'm not sure if I remeber correctly but I thing Herbert was planning to
convert all users over to the crypto API to avoid compile time
dependency.
Yes that's the plan. I've been busy with the crypto testing
stuff but I'll get
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote:
Are we deprecating libcrc32c, then? Or just turning it into a wrapper
around the crypto code?
Maybe I can pick up crc32c_intel_le_hw_byte and crc32c_intel_le_hw
into
one arch-related file and make the current new crypto interface and
On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote:
On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
You could perhaps just use 'unsigned long' here, to avoid the ifdef.
Thanks.
And it would be nice if we could make libcrc32c use this too, rather
than just the 'crypto' users.
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
+static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
+{
+ u32 *key = crypto_tfm_ctx(tfm);
+
+ *key = ~0;
+
+ tfm-crt_ahash.reqsize = sizeof(u32);
+
+ if (cpu_has_xmm4_2)
+ return 0;
+ else
+
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
+static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
+{
+ u32 *key = crypto_tfm_ctx(tfm);
+
+ *key = ~0;
+
+ tfm-crt_ahash.reqsize = sizeof(u32);
+
+ if (cpu_has_xmm4_2)
+ return 0;
+
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
+config CRYPTO_CRC32C_INTEL
+tristate CRC32c INTEL hardware acceleration
+select CRYPTO_HASH
You need some sort of a dependency here. See what the other
assembly algorithms do it.
Cheers,
--
Visit Openswan at
On Mon, 4 Aug 2008 22:04:35 +0800
Herbert Xu [EMAIL PROTECTED] wrote:
There only three crc32c users in the kernel tree and the crypto
interface will serve the perfectly.
isn't it a bit heavy for something as simple as a crc?
(which after all is one instruction now ;0)
--
If you want to
Hi.
On Wed, Jul 30, 2008 at 04:53:01PM -0700, Loc Ho ([EMAIL PROTECTED]) wrote:
This is Linux CryptoAPI user space interface support patch v4. This version
includes:
* Add async support using Linux AIO.
* Interafce to choose Copy to/from user and pinning pages based on size of
data.
*
On Mon, 2008-08-04 at 07:20 -0700, Arjan van de Ven wrote:
On Mon, 4 Aug 2008 22:04:35 +0800
Herbert Xu [EMAIL PROTECTED] wrote:
There only three crc32c users in the kernel tree and the crypto
interface will serve the perfectly.
isn't it a bit heavy for something as simple as a crc?
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Mon, 4 Aug 2008 22:04:35 +0800
Herbert Xu [EMAIL PROTECTED] wrote:
There only three crc32c users in the kernel tree and the crypto
interface will serve the perfectly.
isn't it a bit heavy for something as simple as a crc?
(which after all is
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote:
On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote:
On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
You could perhaps just use 'unsigned long' here, to avoid the ifdef.
Thanks.
And it would be nice if we could make
Chris Mason [EMAIL PROTECTED] wrote:
From a performance point of view I'm probably reading the crypto API
code wrong, but it looks like my choices are to either have a long
standing context and use locking around the digest/hash calls to protect
internal crypto state, or create a new context
On Mon, 2008-08-04 at 23:42 +0800, Herbert Xu wrote:
Chris Mason [EMAIL PROTECTED] wrote:
From a performance point of view I'm probably reading the crypto API
code wrong, but it looks like my choices are to either have a long
standing context and use locking around the digest/hash calls to
Chris Mason [EMAIL PROTECTED] wrote:
Great to hear, that solves my main concern then. There is still the
embedded argument against needing all of crypto api just for libcrc32c.
The existing users are iSCSI, SCTP, Infiniband, all of which are
clearly crucial in the embedded space :)
It does
On Mon, Aug 04, 2008 at 10:06:05AM -0700, Arjan van de Ven wrote:
well you still have that indirect function call
for libcrc32 we could alternatives() that...
I don't see why you couldn't do that for the crypto API too
if you wanted to. That way it would benefit all crypto users
rather
On Tue, Aug 05, 2008 at 01:10:17AM +0800, Herbert Xu wrote:
I don't see why you couldn't do that for the crypto API too
if you wanted to. That way it would benefit all crypto users
rather than just the crc32c (note the extra c) users.
Anyway, the point here is the crc32c is nothing special.
On Mon, 04 Aug 2008 05:35:07 -0400 Austin Zhang wrote:
diff -Naurp linux-2.6/crypto/Kconfig linux-2.6-patch/crypto/Kconfig
--- linux-2.6/crypto/Kconfig 2008-08-04 01:08:00.0 -0400
+++ linux-2.6-patch/crypto/Kconfig2008-08-04 01:59:00.0 -0400
@@ -221,6 +221,17 @@ config
Hi,
What does prevent from simultaneous command execution? Or setkey() vs.
run() race? Do you rely on BKL which 'guards' ioctl execution? How is
-write() protected from ioctl()?
We wasn't plan on protecting this. It is the caller responsibity to call in the
proper order. If the caller want to
On Mon, Aug 4, 2008 at 5:42 PM, Herbert Xu [EMAIL PROTECTED] wrote:
Chris Mason [EMAIL PROTECTED] wrote:
From a performance point of view I'm probably reading the crypto API
code wrong, but it looks like my choices are to either have a long
standing context and use locking around the
Benoit Boissinot [EMAIL PROTECTED] wrote:
Since I couldn't find any ahash user in the tree (outside of tcrypt.c), can
you
provide some example source code as to how to use it (especially
synchonously).
For example the code for the digest_null testing would be fine.
Sure, here is the
27 matches
Mail list logo
