All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	Paul Crowley <paulcrowley@google.com>,
	Greg Kaiser <gkaiser@google.com>,
	Samuel Neves <samuel.c.p.neves@gmail.com>,
	Tomer Ashur <tomer.ashur@esat.kuleuven.be>
Subject: Re: [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator
Date: Sun, 18 Nov 2018 14:46:30 +0100	[thread overview]
Message-ID: <CAHmME9rtsCk8ZLt05xRKMGr4CVRnaUvCaVOS_WX3N22HOat4-A@mail.gmail.com> (raw)
In-Reply-To: <20181117001718.GA175522@gmail.com>

Hi Eric,

On Sat, Nov 17, 2018 at 1:17 AM Eric Biggers <ebiggers@kernel.org> wrote:
> Do you prefer that this be merged before or after Zinc?  It seems it may still
> be a while before the community is satisfied with Zinc (and Wireguard which is
> in the same patchset), and I don't want this blocked unnecessarily...  So on my
> part I'd prefer to just have this merged as-is.

Personally I'd prefer this be merged after Zinc, since there's work to
be done on adjusting the 20->12 in chacha20. That's not really much of
a reason though. But maybe we can just sidestep the ordering concern
all together:

What I suspect we should do is make the initial Zinc merge _without_
those top two patches that replace the crypto api's implementations
with Zinc, and defer those until after the initial merges. Those
commits are already written -- so there's no chance it won't happen
due to laziness or something -- and I think the general merge will go
a bit more smoothly if we wait until after. (Somebody suggested we do
it this way at Plumbers, and was actually a bit surprised I had
already ported the crypto API stuff to Zinc.) This way, Adiantum and
Zinc aren't potentially co-dependent in their initial merges and we
can work on the details carefully with each other after both have
landed. I figure this might make things a little bit less stressful
for both of us. How would you feel about doing it that?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason@zx2c4.com (Jason A. Donenfeld)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator
Date: Sun, 18 Nov 2018 14:46:30 +0100	[thread overview]
Message-ID: <CAHmME9rtsCk8ZLt05xRKMGr4CVRnaUvCaVOS_WX3N22HOat4-A@mail.gmail.com> (raw)
In-Reply-To: <20181117001718.GA175522@gmail.com>

Hi Eric,

On Sat, Nov 17, 2018 at 1:17 AM Eric Biggers <ebiggers@kernel.org> wrote:
> Do you prefer that this be merged before or after Zinc?  It seems it may still
> be a while before the community is satisfied with Zinc (and Wireguard which is
> in the same patchset), and I don't want this blocked unnecessarily...  So on my
> part I'd prefer to just have this merged as-is.

Personally I'd prefer this be merged after Zinc, since there's work to
be done on adjusting the 20->12 in chacha20. That's not really much of
a reason though. But maybe we can just sidestep the ordering concern
all together:

What I suspect we should do is make the initial Zinc merge _without_
those top two patches that replace the crypto api's implementations
with Zinc, and defer those until after the initial merges. Those
commits are already written -- so there's no chance it won't happen
due to laziness or something -- and I think the general merge will go
a bit more smoothly if we wait until after. (Somebody suggested we do
it this way at Plumbers, and was actually a bit surprised I had
already ported the crypto API stuff to Zinc.) This way, Adiantum and
Zinc aren't potentially co-dependent in their initial merges and we
can work on the details carefully with each other after both have
landed. I figure this might make things a little bit less stressful
for both of us. How would you feel about doing it that?

Jason

  parent reply	other threads:[~2018-11-19  0:07 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 23:25 [RFC PATCH v3 00/15] crypto: Adiantum support Eric Biggers
2018-11-05 23:25 ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 01/15] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 02/15] crypto: chacha20-generic - don't unnecessarily use atomic walk Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 03/15] crypto: chacha20-generic - add XChaCha20 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 04/15] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 05/15] crypto: chacha - add XChaCha12 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 06/15] crypto: arm/chacha20 - limit the preemption-disabled section Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 07/15] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 12:41   ` Ard Biesheuvel
2018-11-06 12:41     ` Ard Biesheuvel
2018-11-06 12:41     ` Ard Biesheuvel
2018-11-05 23:25 ` [RFC PATCH v3 08/15] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 12:46   ` Ard Biesheuvel
2018-11-06 12:46     ` Ard Biesheuvel
2018-11-06 12:46     ` Ard Biesheuvel
2018-11-05 23:25 ` [RFC PATCH v3 09/15] crypto: arm/chacha - add XChaCha12 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 14:28   ` Ard Biesheuvel
2018-11-06 14:28     ` Ard Biesheuvel
2018-11-06 14:28     ` Ard Biesheuvel
2018-11-12 18:58     ` Eric Biggers
2018-11-12 18:58       ` Eric Biggers
2018-11-12 18:58       ` Eric Biggers
2018-11-16  6:02       ` Herbert Xu
2018-11-16  6:02         ` Herbert Xu
2018-11-16  6:02         ` Herbert Xu
2018-11-17  0:17         ` Eric Biggers
2018-11-17  0:17           ` Eric Biggers
2018-11-17  0:17           ` Eric Biggers
2018-11-17  0:30           ` Ard Biesheuvel
2018-11-17  0:30             ` Ard Biesheuvel
2018-11-17  0:30             ` Ard Biesheuvel
2018-11-18 13:46           ` Jason A. Donenfeld [this message]
2018-11-18 13:46             ` Jason A. Donenfeld
2018-11-19  5:24             ` [RFC PATCH] zinc chacha20 generic implementation using crypto API code Herbert Xu
2018-11-19  6:13               ` Jason A. Donenfeld
2018-11-19  6:13                 ` Jason A. Donenfeld
2018-11-19  6:22                 ` Herbert Xu
2018-11-19  6:22                   ` Herbert Xu
2018-11-19 22:54                 ` Eric Biggers
2018-11-19 22:54                   ` Eric Biggers
2018-11-19 23:15                   ` Jason A. Donenfeld
2018-11-19 23:15                     ` Jason A. Donenfeld
2018-11-19 23:23                     ` Eric Biggers
2018-11-19 23:23                       ` Eric Biggers
2018-11-19 23:31                       ` Jason A. Donenfeld
2018-11-19 23:31                         ` Jason A. Donenfeld
2018-11-20  3:06                   ` Herbert Xu
2018-11-20  3:06                     ` Herbert Xu
2018-11-20  3:08                     ` Jason A. Donenfeld
2018-11-20  3:08                       ` Jason A. Donenfeld
2018-11-20  6:02               ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Herbert Xu
2018-11-20  6:02                 ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 1/4] crypto: chacha20 - Export chacha20 functions without crypto API Herbert Xu
2018-11-20  6:04                   ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 2/4] zinc: ChaCha20 generic C implementation and selftest Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 3/4] zinc: Add x86 accelerated ChaCha20 Herbert Xu
2018-11-20  6:04                   ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 4/4] zinc: ChaCha20 x86_64 implementation Herbert Xu
2018-11-20 10:32                 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Ard Biesheuvel
2018-11-20 10:32                   ` Ard Biesheuvel
2018-11-20 10:32                   ` Ard Biesheuvel
2018-11-20 14:18                   ` Herbert Xu
2018-11-20 14:18                     ` Herbert Xu
2018-11-20 14:18                     ` Herbert Xu
2018-11-20 16:24                     ` Jason A. Donenfeld
2018-11-20 16:24                       ` Jason A. Donenfeld
2018-11-20 18:51                       ` Theodore Y. Ts'o
2018-11-20 18:51                         ` Theodore Y. Ts'o
2018-11-21  7:55                       ` Herbert Xu
2018-11-21  7:55                         ` Herbert Xu
2018-11-20 16:18                 ` Jason A. Donenfeld
2018-11-20 16:18                   ` Jason A. Donenfeld
2018-11-21  6:01                   ` Herbert Xu
2018-11-21  6:01                     ` Herbert Xu
2018-11-05 23:25 ` [RFC PATCH v3 11/15] crypto: poly1305 - add Poly1305 core API Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 12/15] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 13/15] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 14/15] crypto: adiantum - add Adiantum support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 15/15] fscrypt: " Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-08  6:47 ` [RFC PATCH v3 00/15] crypto: " Martin Willi
2018-11-08  6:47   ` Martin Willi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9rtsCk8ZLt05xRKMGr4CVRnaUvCaVOS_WX3N22HOat4-A@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ebiggers@kernel.org \
    --cc=gkaiser@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulcrowley@google.com \
    --cc=samuel.c.p.neves@gmail.com \
    --cc=tomer.ashur@esat.kuleuven.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.