Syslinux - May 2014 - Issues with syslinux_run_command(str) and parameters

> I didn't see any further communication here; would anyone be
> against my submitting/proposing a patch for this? 
Contributions are always welcome.
> 
> I can see two possible approaches. One approach would be to
> isolate the restriction on user commands away from
> syslinux_run_command / load_kernel. 
> 
> Another would perhaps be to add support for a 'NOTAB' or
> 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so
> the remaining piece would be restricting tab. (And perhaps holding
> shift to get to the console.. Hmm.) 
> 
> I would appreciate any suggestions :)
> 
> Thank you,--Ian 
> 
 
>From the perspective of a final user, breaking the prior behavior of 
directives needs to have very clear advantages.

The NOESCAPE (related to [esc]) and ALLOWOPTIONS (related to [tab]) 
directives have clear (and independent from each other) behaviors. 
Instead of changing their behaviors, the alternatives would be:
_ to find available workarounds (which was already proposed); or,
_ to add new directives.

IIRC, there are no "Global Directives" that apply to specific types 
of kernels or images but not to others (e.g. to modules but not to 
Linux), specially when they have no additional parameter. Introducing 
such type of additional classification could perhaps lead to more 
troubles than it's worth.

Considering that there is already a workaround available, I wonder if 
the inconvenience of having to add "too many" LABEL entries could be 
defeated by reorganizing your Syslinux configuration files.

For instance, using an initial cfg file with the "automatic" entries 
(those that don't require user interaction, such as whichsys.c32, 
ifcpu.c32...) and only then actually showing a [vesa]menu with the UI 
directive (in a second, in-common, cfg file). The individual 
configuration files can be then connected using directives such as 
INCLUDE and CONFIG (typical examples with multiple configuration 
files are available in ArchLinux and Debian, among others).

Regards,
Ady.

Op 2014-05-05 om 23:20 schreef Ady:
>
> > I didn't see any further communication here; would anyone be
> > against my submitting/proposing a patch for this?
>
> Contributions are always welcome.
>
> >
> > I can see two possible approaches. One approach would be to
> > isolate the restriction on user commands away from
> > syslinux_run_command / load_kernel.
> >
> > Another would perhaps be to add support for a 'NOTAB' or
> > 'NOTABTOEDIT' option. There already exists a NOESCAPE setting,
so
> > the remaining piece would be restricting tab. (And perhaps holding
> > shift to get to the console.. Hmm.)
> >
> > I would appreciate any suggestions :)
> >
> > Thank you,--Ian
> >
>
> >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?


   ---------

That text came from a message that I undercepted as moderator.
It was labor some excirise that probably did more harm to the discussion
then the abuse of the discussion order by top quoting.


Groeten
Geert Stappers
--
Leven en laten leven

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