On Mon, Apr 13, 2020 at 1:26 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > > The only benefit of kexec_file_load is that it is simple enough from a > kernel perspective that signatures can be checked. > > kexec_load in every other respect is the more capable and functional > interface. It makes no sense to get rid of it. > > It does make sense to reload with a loaded kernel on memory hotplug. > That is simple and easy. If we are going to handle something in the > kernel it should simple an automated unloading of the kernel on memory > hotplug. > > > I think it would be irresponsible to deprecate kexec_load on any > platform. > > I also suspect that kexec_file_load could be taught to copy the dtb > on arm32 if someone wants to deal with signatures. > > We definitely can not even think of deprecating kexec_load until > architecture that supports it also supports kexec_file_load and everyone > is happy with that interface. That is Linus's no regression rule. TBH, I have seen several active users of kexec_load on arm32 environments and we have been trying to help them with kexec issues on arm32 in recent past as well. So, I agree with Eric's view that probably deprecating this in favour of kexec_file_load will break these existing environment. I tried to do some work at the start of this year to add kexec_file_load support for arm32 in my spare cycles, but I gave up as the arm32 hardware had a broken firmware and couldn't boot latest upstream kernel. May be I try to find some spare cycles in the coming days to do it. But I think since kexec_load is an important interface on these arm32 boards for supporting existing kexec-based bootloaders, we should continue supporting the same until kexec_file_load is supported/mature enough for arm32. Thanks, Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
