[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