[syslinux] RFC: Feature: MENU HIDDEN behaviour on ANY key

[Dany St-Amant]

> Le 11 avr. 2019 à 14:48, Ady Ady via Syslinux <syslinux at syslinux.org> a écrit :
> 
> 
>> 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.

I have to admit that I did not tried MENU SHIFTKEY. I simply assumed that this option was not going to work over serial connection. As these keys are not supposed to send keystroke over serial.

>> *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.

My current configuration was making use of PROMPT 1, but for security reason some options need to be move behind a password which currently can only be achieved via menu.c32. Using a double config files setup might help, but this is just working around the issue and not fixing it. Note that a configuration with PROMPT 1 is also susceptible  to serial console noise. With your suggestion the first "stage" would need a really small TOTALTIMEOUT to hide the issue. A short and quick to type label for second stage invocation could work.

> 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.

Based on hide_key[] definitions one would need to list 0x12a entries, some of which likely not having a worldly description to used by MENU HIDDENKEY.

>> *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.

Sorry, I have not done my homework here. My suggested behaviour was based on the definition of MENU HIDDENKEY on the wiki which doesn't mark command... as optional. The current behaviour for HIDDENKEY without a command causes an error when the key is hit: "Loading ... failed:" (as the code try to load file "" from current location). This failure causes menu.c32 to be restarted (the timeout get restarted) without reloading any files. Note that similar behaviour also occurs if a kernel line is missing the kernel name. From the boot prompt, using such label lead to an odd behaviour.

> 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.

Right, changing default behaviour is bad. But should the behaviour of currently invalid syntax be kept?

> 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.


Thanks for the suggestions,
Dany