linux/crypto/tcrypt.c, branch v2.6.13

[CRYPTO]: Use CPU cycle counters in tcrypt

2005-06-22T20:29:03Z

After using this facility for a while to test my changes to the cipher crypt() layer, I realised that I should've listend to Dave and made this thing use CPU cycle counters :) As it is it's too jittery for me to feel safe about relying on the results. So here is a patch to make it use CPU cycles by default but fall back to jiffies if the user specifies a non-zero sec value. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[CRYPTO]: Use template keys for speed tests if possible

2005-06-22T20:27:51Z

The existing keys used in the speed tests do not pass the 3DES quality check. This patch makes it use the template keys instead. Other algorithms can supply template keys through the same interface if needed. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[CRYPTO]: Add cipher speed tests

2005-06-22T20:27:23Z

From: Reyk Floeter I recently had the requirement to do some benchmarking on cryptoapi, and I found reyk's very useful performance test patch [1]. However, I could not find any discussion on why that extension (or something providing a similar feature but different implementation) was not merged into mainline. If there was such a discussion, can someone please point me to the archive[s]? I've now merged the old patch into 2.6.12-rc1, the result can be found attached to this email. [1] http://lists.logix.cz/pipermail/padlock/2004/000010.html Signed-off-by: Harald Welte Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[CRYPTO]: Kill unnecessary strncpy from tcrypt

2005-06-22T20:26:36Z

It seems that bad code tends to get copied (see test_cipher_speed). So let's kill this idiom before it spreads any further. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[CRYPTO]: White space and coding style clean up in tcrypt

2005-06-22T20:26:03Z

Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!