Hi Paul,
> * lib/af_alg.h: Use imperatives and tighten up wording.
> ...
> -/* Computes a message digest of the contents of a file.
> +/* Compute a message digest of the contents of a file.
> ...
> - If successful, this function fills RESBLOCK and returns 0.
> - Upon failure, it returns a nega
Oops, I had left some unneeded module dependencies.
2018-05-06 Bruno Haible
Followup to 'af_alg: New module.'.
* modules/crypto/md5 (Depends-on): Remove sys_socket, sys_stat.
* modules/crypto/sha1 (Depends-on): Likewise.
* modules/crypto/sha256 (Depends-on): Li
Bruno Haible wrote:
The GNU Coding Standards [1] don't favour either, although I have vague
memories that 20 years ago, it advocated imperative style.
Yes, I have the same vague memory, and still prefer imperative style in many
cases. For routine use in comments, the imperative style is typic
This patch adds the configure option.
Assaf suggested to let it turned off by default, but I prefer to turn it on
by default because
* All known past bugs of this API are with empty inputs, and the gnulib
code is careful to avoid this scenario.
* The crypto code is in the kernel for quite
Each time you see a call to the 'fileno' function, you should ask yourself
"What if some data has already been written to / read from the stream?
What about the buffers in the FILE structure that the kernel doesn't
know about?"
So I extended the test suite to test also the case of a FILE stream th
When the function returns -EINVAL, a socket is not closed.
2018-05-06 Bruno Haible
af_alg: Fix a resource leak.
* lib/af_alg.c (afalg_stream): Close socket before returning -EINVAL.
New local variable 'result'.
diff --git a/lib/af_alg.c b/lib/af_alg.c
index 79e2195..0
On Sun, May 6, 2018 at 3:11 AM, Paul Eggert wrote:
> Bruno Haible wrote:
>
>> The GNU Coding Standards [1] don't favour either, although I have vague
>> memories that 20 years ago, it advocated imperative style.
>
>
> Yes, I have the same vague memory, and still prefer imperative style in many
> c
It is to be expected that crypto hardware would not only speed up
sha1_stream but also sha1_buffer (where the input is in memory).
As a first step towards this, I'm adding benchmarks of the sha1_buffer etc.
functions.
The way to use this benchmark is, from a testdir:
$ gltests/bench-sha1 10
When --without-linux-crypto is in effect and the file "af_alg.h" gets included
but the function is not used, gcc produces a warning.
The best way to avoid this warning is to mark the function as inline.
Additionally, this function is really meant to be inlined, also on non-GCC
compilers.
2018-05
It is to be expected that crypto hardware would not only speed up
sha1_stream but also sha1_buffer (where the input is in memory).
The second step is to add to 'af_alg' a function that can be used by each of
md5_buffer, sha1_buffer, etc.
2018-05-06 Bruno Haible
af_alg: Add ability to
Now, here's a draft patch for adding support for AF_ALG also for the
sha1_buffer etc. functions.
But I have a problem here: On 4 different systems, I don't get a speedup
from this patch.
To benchmark it, I use this set of commands:
$ ./gnulib-tool --create-testdir --dir=testdir --single-configur
On Sun, May 6, 2018 at 6:01 PM, Bruno Haible wrote:
> Now, here's a draft patch for adding support for AF_ALG also for the
> sha1_buffer etc. functions.
>
> But I have a problem here: On 4 different systems, I don't get a speedup
> from this patch.
>
> To benchmark it, I use this set of commands:
Hi Matteo,
> I've checked out latest gnulib, and after double checking that commit
> 761523ddea70f0456b556c09868910686751fff5 was there I ran this:
Please take commit 55efbb1178e045d52b0f52a2160f3d943c4f8a2c plus the patch
from https://lists.gnu.org/archive/html/bug-gnulib/2018-05/msg00035.html.
On Sun, May 6, 2018 at 9:00 PM, Bruno Haible wrote:
> Hi Matteo,
>
>> I've checked out latest gnulib, and after double checking that commit
>> 761523ddea70f0456b556c09868910686751fff5 was there I ran this:
>
> Please take commit 55efbb1178e045d52b0f52a2160f3d943c4f8a2c plus the patch
> from https:
Matteo Croce wrote:
> I have 55efbb1178e045d52b0f52a2160f3d943c4f8a2c but the patch fails to apply.
Oops, I goofed with "git diff". Here's the correct patch to test.
Bruno
diff --git a/lib/md5.c b/lib/md5.c
index 9b414aa..69240b3 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -221,6 +221,14 @@ process
Bruno Haible wrote:
Oops, I goofed with "git diff". Here's the correct patch to test.
I tried those bench-md5 benchmarks on two platforms, with somewhat more
disappointing results.
I observed a real-time slowdown ranging from 11% (large buffers) to 22x (small
buffers) on Intel Xeon E3-1225
Hello Bruno and all,
On Sun, May 06, 2018 at 12:31:36PM +0200, Bruno Haible wrote:
> Assaf suggested to let it turned off by default, but I prefer to turn it on
> by default because
I'd still suggest turning it off by default to be more conservative.
Few things to consider:
> * All known pas
17 matches
Mail list logo
