On Mon, 5 Oct 2020 at 08:19, Christoph Hellwig <h...@infradead.org> wrote: > > On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote: > > On Sun, 4 Oct 2020 at 20:48, Stephan M??ller <smuel...@chronox.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.
Fair enough. But this means we should fix the jitterentropy driver rather than sidestepping the issue by only allowing it to be built in a way where we don't happen to notice that the symbol in question is not meant for general consumption. If jitterentropy is a special case, we could put a alternate non-'static inline' version of random_get_entropy() in the core kernel, and only export it if JITTER_ENTROPY is built as a module in the first place. But I'd prefer it if jitterentropy switches to an API that is suitable for driver consumption.
