On Fri, Jul 15, 2016 at 04:42:40PM +0200, Petr Tesarik wrote: > On Fri, 15 Jul 2016 08:51:14 -0400 > Vivek Goyal <vgoyal at redhat.com> wrote: > > > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote: > > > On Fri, 15 Jul 2016 07:57:22 +0800 > > > joeyli <jlee at suse.com> wrote: > > > > > > > Hi Vivek > > > > > > > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote: > > > > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote: > > > > > > This patch adds a new "--fallback-kexec" option to give a chance to > > > > > > fallback to old kexec syscall when file based kexec syscall operation > > > > > > failed. > > > > > > > > > > I think caller should switch to using different interface if need be. But > > > > > I don't see much point in providing an option for this in kexec-tools. > > > > > > > > > > Vivek > > > > > > > > > > > > > OK~ Understood! > > > > > > > > Thanks for Baoquan's and your opinion for this patch. > > > > > > Is there some sort of diagnostics, so a calling script can determine > > > whether kexec failed, because there's no suppor for kexec_file_load(2) > > > or for a different reason? > > > > Will we not get -ENOSYS if kexec_file_load() is not implemented? > > Sure, the kexec code will see a beautiful ENOSYS in errno, but it > merely prints this message on stderr (possibly with a different error > string if not linked against glibc): > > kexec_file_load failed: Function not implemented > > ...and exits with status 255 (same for any other error). Which is, um, > not very friendly to automated error handling... So what are the options? One should return different error codes as returned by glibc? But bash or other script will not have a library to translate it. I guess scripts will have to hard code the meaning of a particular return code. BTW, user can always try kexec_file_load() and if it fails, try older version of syscall and that should work for lot of use cases? Vivek
