[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Aug 2018 18:48:59 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arch@...r.kernel.org, Eric Biggers <ebiggers3@...il.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Andrew Lutomirski <luto@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Samuel Neves <sneves@....uc.pt>,
"Daniel J . Bernstein" <djb@...yp.to>,
Tanja Lange <tanja@...erelliptic.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
Karthikeyan Bhargavan <karthik.bhargavan@...il.com>
Subject: Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
> On Aug 7, 2018, at 4:48 PM, Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hey Andy,
>
>> On Tue, Aug 7, 2018 at 12:43 PM Andy Lutomirski <luto@...capital.net> wrote:
>> For "zinc: add simd helper", I think it should be in include/linux,
>> and include/linux/simd.h should (immediately or maybe in the future)
>> include <asm/simd.h> to pick up arch-specific stuff. And the patch
>> should get sent to linux-arch@...r.kernel.org.
>
> I guess you saw my prompt about that in the previous commit message?
> Based on your encouragement, I implemented it:
> https://git.zx2c4.com/linux-dev/commit/?h=simd This is _far_ more
> invasive than I wanted to be, as I don't want this patch submission to
> grow unwieldy and never be merged, but I guess we can roll with this
> for now...
>
I really wish we had a way to see that we use asm-generic’s copy of a header in all cases except where an arch opts out.
>> In your blake2s_arch() implementation, you're not passing in a
>> simd_context_t. Is that still a work in progress? I thought the plan
>> was to pass it in rather than doing the check in the _arch()
>> functions.
>
> I'm inclined to do the explicit context passing only when a function
> is likely to be used in that kind of environment, and adjust as
> needed. Long term, anyway, that API will be removed once the x86 guys
> figure out lazy FPU restoration and the amortization doesn't add
> anything.
Fair enough.
>
> Jason
Powered by blists - more mailing lists