On 01/07/20 1:16 pm, Dave Young wrote: > On 06/29/20 at 05:26pm, Hari Bathini wrote: >> Hi Petr, >> >> On 29/06/20 5:09 pm, Petr Tesarik wrote: >>> Hi Hari, >>> >>> is there any good reason to add two more functions with a very similar >>> name to an existing function? AFAICS all you need is a way to call a >>> PPC64-specific function from within kexec_add_buffer (PATCH 4/11), so >>> you could add something like this: >>> >>> int __weak arch_kexec_locate_mem_hole(struct kexec_buf *kbuf) >>> { >>> return 0; >>> } >>> >>> Call this function from kexec_add_buffer where appropriate and then >>> override it for PPC64 (it roughly corresponds to your >>> kexec_locate_mem_hole_ppc64() from PATCH 4/11). >>> >>> FWIW it would make it easier for me to follow the resulting code. >> >> Right, Petr. >> >> I was trying out a few things before I ended up with what I sent here. >> Bu yeah.. I did realize arch_kexec_locate_mem_hole() would have been better >> after sending out v1. Will take care of that in v2. > > Another way is use arch private function to locate mem hole, then set > kbuf->mem, and then call kexec_add_buf, it will skip the common locate > hole function. Dave, I did think about it. But there are a couple of places this can get tricky. One is ima_add_kexec_buffer() and the other is kexec_elf_load(). These call sites could be updated to set kbuf->mem before kexec_add_buffer(). But the current approach seemed like the better option for it creates a single point of control in setting up segment buffers and also, makes adding any new segments simpler, arch-specific segments or otherwise. Thanks Hari _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec