[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 0/4] Use AF_ALG in checksum utilities

From: Paul Eggert
Subject: Re: [PATCH v3 0/4] Use AF_ALG in checksum utilities
Date: Mon, 7 May 2018 00:36:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Assaf Gordon wrote:

I think that for the same reason that --with-openssl defaults to 'no'
and not to 'auto' applies here.

This is a good point; it's easier to understand and explain if the two options have similar defaults.

I'm not sure there is significant improvement of using af_alg
compared to using OpenSSL, unless one has additional crypto hardware
(which is perhaps more common in embedded systems? but them their
users compile dedicated packages anyhow).

Is there some easy way to detect whether the hardware supports crypto directly? If so, we could use the new interface only on platforms where that is true. This should alleviate many of the qualms you express.

It won't matter to a single user on a desktop, but imagine
a shared server at a university, when all of a sudden a sysadmin
might see a very very high %SYS load - with almost no way to disagnose
what's going on.

Why won't sysadmins be able to diagnose this? Isn't %SYS time accounted for?
If I'm not mistaken, running
    "./configure --with-openssl=yes"
Still detects and uses crypto API (but also links with libcrypto).
Only "--with-openssl=yes --without-linux-crypto" disables it.
I think this is quite unexpected, perhaps even a regression:
if someone explicitly asked to use OpenSSL, they certainly don't
want to not use it...

Good catch, thanks.

Perhaps we should have one --with option rather than two? This might help reduce the confusion mentioned above.

I installed the attached patch to try to fix the minor glitches you mentioned. The code glitches were my fault (blush).

Attachment: 0001-af_alg-Pacify-enable-gcc-warnings.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]