[syslinux] Issues with syslinux_run_command(str) and parameters

H. Peter Anvin hpa at zytor.com
Wed May 7 14:38:09 PDT 2014


>>
>> >From the perspective of a final user, breaking the prior behavior of
>> directives needs to have very clear advantages.
> 
> Reviewing the commit history, I would say that the prior behavior is currently broken.
> 
> The ALLOWOPTIONS feature was added in 2004:
> http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10
> And syslinux_run_command() in 2007:
> http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634
> 
> At this point, syslinux_run_command is using the equivalent of
> create_args_and_load(), a function that is *not* negatively affected
> by ALLOWOPTIONS.
> 
> The behavior was changed in 2013 to use load_kernel to *add* label support:
> http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05
> 
> At this point the 8 or 9 com32 modules I listed earlier stopped working
> when ALLOWOPTIONS was set. This is a change from the previous 6 years
> of behavior.
> 
> But, if we still have different views on this, it looks like ALLOWOPTIONS
> is internally referred to as 'allowedit' in the menu code. Perhaps
> we can separate them there, maintaining an ALLOWOPTIONS' variable for
> load_kernel to check, but also adding a ALLOWEDIT option that the menu
> can use to restrict the Tab to edit functionality.
> 
> Thoughts?
> 

I do agree that the current behavior is most likely an inadvertent
regression.

	-hpa




More information about the Syslinux mailing list