[syslinux] RFC: Feature: MENU HIDDEN behaviour on ANY key
Ady Ady
ady-sf at hotmail.com
Thu Apr 11 11:48:07 PDT 2019
> Hello,
>
> Here's a small enhancement feature for menu.c32. Looking for feedback before
> starting any coding (not sure when I'll have time for implementation)
>
> Regards,
> Dany St-Amant
>
>
> *Problem statement*
>
> When MENU HIDDEN is used on an headless server, any noise on the serial
> console can interrupt the boot; it would be preferable if there only specific
> keys were allowed to interrupt, reducing the probability of unwanted
> interruption. Even with TOTALTIMEOUT present, there's a delay present as
> TOTALTIMEOUT has to be large enough to make it useable during intentional boot
> interruption.
Sounds like 'MENU SHIFTKEY' would be useful for your case.
>
> *Basic behaviour change*
>
> Provide a way to assign "reveal menu" to specific key(s)
One possible alternative would be to separate the cfg, or at least to not
default to menu.c32. The initial cfg would use 'PROMPT 1' and 'TIMEOUT', and
the 'DEFAULT' directive would point to the default LABEL, instead of triggering
menu.c32. The 'UI' directive would not be used in this initial cfg file either,
of course. Then, a certain label would trigger the menu, at user's choice. That
LABEL could be one "m" character. Using several 'SAY' directives can work as
on-screen help "menu" for simple LABELs (no need to use fancy menus), and
DISPLAY files can even send an output result to the serial console different
than to a normal screen (but, please note that DISPLAY files are not always
working correctly for UEFI). So, here we already have several potential
alternatives.
I would also suggest reading
http://www.syslinux.org/wiki/index.php/Directives/special_keys
Independently of such potential alternative(s), the 'MENU SHIFTKEY' directive
(explained in the "MENU" wiki page and also mentioned in the "special keys"
wiki page) could be also combined with other directives, or it can be used
without the 'MENU HIDDEN' directive.
> Provide a default behaviour for unassigned keys (other than current "reveal
> menu")
For a workaround for ANY and/or unassigned keys, you could have multiple 'MENU
HIDDEN' directives, each with a list of multiple keys.
> *Possible user interface change*
>
> MENU HIDDENMENUKEY key[,key]
> MENU HIDDDENKEY key[,key] [command...]
> Add ANY as an acceptable value for key
> Make command optional, defaulting to boot default.
>
> *Behaviour*
>
> If pressed key is defined by HIDDENKEY, that action is always taken.
> no HIDDENMENUKEY, no HIDDENKEY ANY: all keys bring the menu (current
> behaviour)
> HIDDENMENUKEY ANY: all keys bring the menu (current behaviour)
> HIDDENMENUKEY Esc, HIDDENKEY ANY (without commands): Esc brings the menu, all
> keys autoboot
> HIDDENMENUKEY Esc, no HIDDENKEY ANY: Esc brings the menu, all keys trigger
> nothing.
>
> *Exclusion*
>
> No similar support for boot prompt.
> No code/behaviour analysis made for cmenu.c32
>
> *Affected code* (outside config parsing)
>
> menumain.c:do_hidden_menu()
> Extra comparison when handling mygetkey(),ignoring unbound key if ANY not
> assigned (or defaulted). Return NULL, if hide_key[key] matches HIDDENMENUKEY.
> A few extra globals likely required to track/reference pseudo-commands "reveal
> menu" and "boot default" inside hide_key[] table. Need to use/steal an unused
> entry of hide_key[] as the ANY key.
>
> *Rejected/discarded interface option*
>
> MENU HIDDENSECUREKEY key[,key] [STRICT]
> MENU HIDDENDEFAULTKEY 0|1
> MENU HIDDENANYKEY MENU|IGNORE|BOOT
> MENU HIDDENKEY ANY|key[,key] MENU|IGNORE|BOOT|command...
>
> Last one is rejected to avoid collision with exiting configuration which might
> be using label matching the keywords.
Regarding the default command (i.e. when the command is not explicitly written
at the end of the directive), I think the default behavior should (continue to)
be to do nothing, as if the directive was not there. Such behavior is
consistent with other directives too. Have you tested what happens as it is
right now? FWIW, I disagree with breaking the current default behavior.
If the typical / normal / frequent use is with no menu, then isn't it simpler
to have 'COM32 menu.c32' under a LABEL, or even as multiple equivalent labels?
FWIW, I don't mind the introduction of new directives (I have my own proposals
too), but changing the default behavior of current directives is not something
I'm happy about; just my personal opinion.
Considering the extremely low pace of development, and the fact that too many
patches and suggestions have been ignored during the last few years, perhaps
evaluating some already-available alternatives (such as those mentioned above)
might be more effective.
Regards,
Ady.
More information about the Syslinux
mailing list