public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Holger Dengler <dengler@linux.ibm.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	x86@kernel.org, Will Deacon <will@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Borislav Petkov <bp@suse.de>, Heiko Carstens <hca@linux.ibm.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Harald Freudenberger <freude@linux.ibm.com>
Subject: Re: [PATCH v2] random: handle archrandom in plural words
Date: Wed, 3 Aug 2022 14:01:31 +0200	[thread overview]
Message-ID: <f2c6f744-7139-05b6-6d96-4e207dcd9c1f@linux.ibm.com> (raw)
In-Reply-To: <YtqIbrds53EuyqPE@zx2c4.com>

Hi Jason,

On 22/07/2022 13:22, Jason A. Donenfeld wrote:
> On Fri, Jul 22, 2022 at 10:08:05AM +0200, Holger Dengler wrote:
>> Why not changing the API to take bytes instead of words? Sure, at the
>> moment it looks like all platforms with TRNG support are able to
>> deliver at least one word, but bytes would be more flexible. 
> 
> The idea is to strike a sweet spot between capabilities. S390x is fine
> with byte-level granularity up to arbitrary lengths, while x86 is best
> with word-level granularity of length 1. The happy intersection between
> the two is just word-level granularity of arbitrary length. Yes we
> _could_ introduce a lot of code complexity by cascading the x86 case
> down into smaller and smaller registers, ignoring the fact that it's no
> longer efficient below 32- or 64-bit registers depending on vendor. But
> then we're relying on the inliner to remove all of that extra code,
> since all callers actually only ever want 32 or 64 bytes. Why bloat for
> nothing? The beauty of this approach is that it translates very
> naturally over all the various quirks of architectures without having to
> have a lot of coupling code.

You're absolutely right. Your solution addresses all needs of current architectures. My proposal was just meant as preparation for the case, that new (smaller) architectures may come up in the future with a TRNG support, but with other granularity. But anyhow: we can handle it as soon as it happens, fine with me.


-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@linux.ibm.com

      reply	other threads:[~2022-08-03 12:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YtP1+MJ1tNdJA60l@zx2c4.com>
2022-07-17 20:03 ` [PATCH v2] random: handle archrandom in plural words Jason A. Donenfeld
2022-07-18  6:31   ` Michael Ellerman
2022-07-18  6:46     ` Gabriel Paubert
2022-07-20  3:03       ` Michael Ellerman
2022-07-19 12:42   ` Mark Rutland
2022-07-19 12:46     ` Jason A. Donenfeld
2022-07-19 13:02       ` [PATCH v3] random: handle archrandom with multiple longs Jason A. Donenfeld
2022-07-19 13:17         ` Mark Rutland
2022-07-19 13:48         ` Catalin Marinas
2022-07-22 12:06         ` Heiko Carstens
2022-07-25  9:19         ` Borislav Petkov
2022-07-25  9:26           ` Jason A. Donenfeld
2022-07-25  9:36             ` David Laight
2022-07-25  9:37               ` Jason A. Donenfeld
2022-07-25 11:25         ` Borislav Petkov
2022-08-01 14:46         ` Harald Freudenberger
2022-08-01 14:50           ` Jason A. Donenfeld
2022-07-22  8:08   ` [PATCH v2] random: handle archrandom in plural words Holger Dengler
2022-07-22 11:22     ` Jason A. Donenfeld
2022-08-03 12:01       ` Holger Dengler [this message]

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=f2c6f744-7139-05b6-6d96-4e207dcd9c1f@linux.ibm.com \
    --to=dengler@linux.ibm.com \
    --cc=Jason@zx2c4.com \
    --cc=agordeev@linux.ibm.com \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=freude@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox