[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrXy6QXLKTih9e=ceMZes=SjHEMGg+vW1sXdiRg5Qaxt7g@mail.gmail.com>
Date: Tue, 27 Dec 2016 11:00:17 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Andy Lutomirski <luto@...nel.org>,
Netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Eric Biggers <ebiggers3@...il.com>,
Tom Herbert <tom@...bertland.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be
used without shash
On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
> On 12/27/2016 10:58 AM, Herbert Xu wrote:
>>
>> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>>
>>>
>>> According to Daniel, the networking folks want to let embedded systems
>>> include BPF without requiring the crypto core.
>>
>>
>> Last I checked the IPv4 stack depended on the crypto API so this
>> sounds bogus.
>
>
> I think there's a bit of a mixup here with what I said. To clarify,
> requirement back then from tracing folks was that bpf engine and
> therefore bpf syscall can be build w/o networking enabled for small
> devices, so dependencies preferably need to be kept on a absolute
> minimum, same counts for either making it suddenly a depend on
> CRYPTO or a select CRYPTO for just those few lines that can be
> pulled in from lib/ code instead.
Somehow I had that in my head as "networking" not "tracing", probably
because of the TCA stuff. Whoops.
Anyway, I'm rewriting the crypto part of the patch completely based on
Ard's feedback.
Powered by blists - more mailing lists