All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: grub-devel@gnu.org
Subject: Re: [PATCH] [RFC] Add exitcode support
Date: Sat, 23 Jan 2016 11:26:19 +0300	[thread overview]
Message-ID: <56A3392B.5070008@gmail.com> (raw)
In-Reply-To: <56A27D9F.7040403@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

22.01.2016 22:06, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> On 18.08.2015 21:17, Ben Hildred wrote:
>> Let's assume for a minute that I have compiled grub as a multiboot image
>> and have called it from another bootloader, say iPXE.Now iPXE assumes
>> that any false return is an error. What happens when grub returns with
>> exit next, does iPXE get a true or false? What about exit fred where
>> fred is not defined by any platform? What if I do an exit config which
>> is only defined for coreboot?
> Neither multiboot nor coreboot have any return semantics. The situation
> with current platforms is as follows:
> No return/exit semantics at all or machine shutdown:
> i386_coreboot, i386_qemu, i386_multiboot, mips_qemu_mips, mips_loongson
> no-args exit:
> *-ieee1275, i386-pc, mips-arc
> Xen semantics (crash vs poweroff):
> *-xen
> EFI semantics:
> *-efi
> Unix-like semantics:
> arm-uboot, emu
> 
> Emu is of no real interest and I have no idea what Uboot does with
> return code but I suppose nothing.
> 
> This leaves us only with xen and EFI semantics. Xen is enough of outlier
> to handle it separately. So only EFI is remaining.
> 
> On i386-pc the default behaviour of exit is to try next boot entry. EFI
> should probably do the same. What is the current behaviour of grub_exit
> and what is the value in returning EFI_SUCCESS ?

Currently it returns EFI_SUCCESS that tells firmware boot manager to
return to menu and stop attempting to load further boot options. I.e.
this is directly opposite to what i386-pc.

OTOH I still find it useful to be able to explicitly return to boot menu
from GRUB (or EFI Shell for that matter).

> Can we have returncode-aware command to be EFI-specific?
> 

I'm fine with changing default EFI exit code to be not EFI_SUCCESS (but
this should be commented in sources) and to have fwmenu (similar to
fwsetup) that explicitly returns EFI_SUCCESS.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2016-01-23  8:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 17:30 [PATCH] [RFC] Add exitcode support dann frazier
2015-08-18 18:03 ` Ben Hildred
2015-08-18 18:56   ` Dann Frazier
2015-08-18 19:17     ` Ben Hildred
2015-08-18 22:00       ` Dann Frazier
2016-01-22 19:06       ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-23  8:26         ` Andrei Borzenkov [this message]
2016-01-25 19:15           ` Vladimir 'phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A3392B.5070008@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.