[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201005061918.GB1856@infradead.org>
Date: Mon, 5 Oct 2020 07:19:18 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Stephan M??ller <smueller@...onox.de>,
Palmer Dabbelt <palmerdabbelt@...gle.com>,
Christoph Hellwig <hch@...radead.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Android Kernel Team <kernel-team@...roid.com>,
kernel test robot <lkp@...el.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] crypto: jitterentropy - bind statically into kernel
On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote:
> On Sun, 4 Oct 2020 at 20:48, Stephan M??ller <smueller@...onox.de> wrote:
> >
> > The RISC-V architecture is about to implement the callback
> > random_get_entropy with a function that is not exported to modules.
>
> Why is that? Wouldn't it be better to export the symbol instead?
get_cycles is a low-level time keeping detail that really should not
be exported, and at least for RISC-V this would be the only modular
user. Once that is sorted out I'll audit other common architectures
to drop the export, as it isn't something that should be used in ramdom
driver code.
Powered by blists - more mailing lists