Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220928165018.73496-1-Jason@zx2c4.com>
In-Reply-To: <20220928165018.73496-1-Jason@zx2c4.com>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Fri, 25 Nov 2022 12:10:58 +0800
Message-ID: <CACXcFmkyoNu5fU=pAxPNY-bwGyJ5bd2LkmVkxHGOubZmbbzT_Q@mail.gmail.com>
Subject: Re: [PATCH] random: add 8-bit and 16-bit batches
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Sep 29, 2022 at 1:33 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> There are numerous places in the kernel that would be sped up by having
> smaller batches. ...

>  void get_random_bytes(void *buf, size_t len);
> +u8 get_random_u8(void);
> +u16 get_random_u16(void);
>  u32 get_random_u32(void);
>  u64 get_random_u64(void);
>  static inline unsigned int get_random_int(void)

To me, the 32-bit & 64-bit functions look like an
obviously good idea. However, I cannot see
that the 8-bit or 16-bit functions are needed.

Even library functions like getchar() return an
int & whatever you return, it is going to be
handled as an int-sized item if it goes in a
register, so what's the point?