grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] normal/menu: Do not treat error values as key presses


From: Daniel Kiper
Subject: Re: [PATCH] normal/menu: Do not treat error values as key presses
Date: Wed, 6 Feb 2019 12:49:34 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Feb 05, 2019 at 05:29:13PM +0100, Paul Menzel wrote:
> Date: Sat, 4 Feb 2019 22:39:37 +0100
>
> Some terminals, like `grub-core/term/at_keyboard.c`, return `-1` in case
> they are not ready yet.
>
>       if (! KEYBOARD_ISREADY (grub_inb (KEYBOARD_REG_STATUS)))
>         return -1;
>
> Currently, that is treated as a key press, and the menu time-out is
> cancelled/cleared. This is unwanted, as the boot is stopped and the user
> manually has to select a menu entry. Therefore, adapt the condition to
> require the key value also to be greater than 0.
>
> `GRUB_TERM_NO_KEY` is defined as 0, so the condition could be collapsed
> to greater or equal than (≥) 0, but the compiler will probably do that
> for us anyway, so keep the cases separate for clarity.
>
> This is tested with coreboot, the GRUB default payload, and the
> configuration file `grub.cfg` below.
>
> For GRUB:
>
>     $ ./autogen.sh
>     $ ./configure --with-platform=coreboot
>     $ make -j`nproc`
>     $ make default_payload.elf
>
> For coreboot:
>
>     $ more grub.cfg
>     serial --unit 0 --speed 115200
>     set timeout=5
>
>     menuentry 'halt' {
>         halt
>     }
>     $ build/cbfstool build/coreboot.rom add-payload \
>         -f /dev/shm/grub/default_payload.elf -n fallback/payload -c lzma
>     $ build/cbfstool build/coreboot.rom add -f grub.cfg -n etc/grub.cfg -t raw
>     $ qemu-system-x86_64 --version
>     QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-2+b1)
>     Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
>     $ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio -nic 
> none
>
> Currently, the time-out is cancelled/cleared. With the commit, it is not.
>
> With a small GRUB payload, this the problem is also reproducible on the
> ASRock E350M1.
>
> Link: http://lists.gnu.org/archive/html/grub-devel/2019-01/msg00037.html
> Signed-off-by: Paul Menzel <address@hidden>

Reviewed-by: Daniel Kiper <address@hidden>

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]