> We do not remove kexec_load at all, it is indeed helpful in many cases > as all agreed. But if we have a bug reported for both we may fix > kexec_file_load first because it is usually easier, also do not need to > worry about too much about old kernel and new kernel compatibility. > > For example the recent breakage we found in efi path, kexec_file_load > just work after the efi cleanup, but kexec_load depends on the ABI we > added, so we must fix it as below: > https://lore.kernel.org/linux-efi/20200410135644.GB6772@xxxxxxxxxxxxxxxxxxxxxxxxxx/ Also, we have some specific sysfs files exported for kexec-tools use /sys/firmware/efi/runtime-map/* and a few other table addresses: fw_vendor runtime and config_table under /sys/firmware/efi That is only used by userspace kexec_tools for kexec_load, now the runtime field is useless because of Ard's cleanup in efi code, but we have to keep it there, older kexec-tools will need it. In this case kexec_file_load do not need those hacks at all. So in the future if we have to invent some kernel/userspace abi only for kexec_load we should be careful and maybe reject if no strong reason. Thanks Dave
