On Thu, Nov 14, 2019 at 07:11:29PM +0100, Richard Henderson wrote: > On 11/14/19 3:25 PM, Mark Rutland wrote: > > As I asked previously, please separate the common case and the boot-cpu > > init-time case into separate functions. > Ok, beyond just making arch_get_random_seed_long be a function pointer, how? > I honestly don't understand how what you want is different from what's here. I believe that what Mark is saying when he says you should change the arch hooks is that you should change the interface between the core code and the architecture code to separate the runtime and early init interfaces with the goal of making it clear the separation between the two. > > Any boot-time seeding should be in a separate function that external > > callers cannot invoke at runtime. Either have an arch function that the > > common random code calls at init time on the boot CPU, or have some > > arch_add_foo_entropy() function that the arm64 code can call somewhere > > around setup_arch(). > What "external callers" are you talking about? Again Mark can correct me if I'm wrong here but anything that isn't the arch code or the core random code. > As for arch_add_boot_entropy() or whatnot... you're now you're asking for > non-trivial changes to the common drivers/char/random.c code. I'm not keen on > designing such a thing when I really don't know what the requirements are. In > particular, how it would differ from what I have. The biggest issue here is one of reviewability and maintainability around early use of the capabilities code. Without being really up to speed on those interfaces it can be hard to tell what conditions are true when and what interfaces are safe to use at any given point in boot which makes things harder to work with. This is especially true when we start to mix in things like preemption disables which also need a lot of attention. Avoiding mixing code that needs to run in both init and normal runtime contexts in the same function makes things easier to understand. Looking briefly at the random code you may find that the existing add_device_randomness() is already close to the arch_add_foo_entropy() suggested by Mark if not actually good enough, data injected with that is not going to be credited as entropy but it will feed into the pool.
Attachment:
signature.asc
Description: PGP signature
