[syslinux] Issues with syslinux_run_command(str) and parameters
Ady
ady-sf at hotmail.com
Wed May 7 16:25:25 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
>
As common user, my understanding of the relevant global directives
is:
_ PROMPT: Whether (or not) to directly execute the DEFAULT (or UI if
present) directive.
_ NOESCAPE: Whether (or not) to allow the usage of the [ESC / SHIFT /
ALT / CAPS LOCK / SCROLL LOCK] keys.
_ NOCOMPLETE: Whether (or not) to allow the TAB key to display
predefined labels in the command line.
_ IMPLICIT: Whether (or not) to limit the execution of commands to
predefined labels only.
_ALLOWOPTIONS: Whether (or not) to allow the user to change
(add/edit/erase) the command line _arguments_.
There are more global directives, but those are the relevant ones for
this case.
Fortunately, there is no mention about acting over a specific type of
kernels (or not to act on others). In case a global directive is
related to some specific type of "anything", that "anything" is
specifically used as argument of the relevant command (FONT and
KBDMAP global directives as examples), or is specifically mentioned
in the definition of the directive (e.g. when related to labels).
I don't know what these directives used to do 10 years ago. I do know
that they are currently acting according to what it is expected by
the user.
As user, I don't see a reason to change these current behaviors,
specially if the suggested change would differentiate the (global)
behavior depending on type of kernel. What's next? Global directives
behaving differently depending on zImage / bzImage / memdisk / c32
module / Linux version?
If there were no alternative to a certain desired behavior, then I
could understand the doubts (in fact, I could mention certain
situations not being currently supported).
As you might have noticed, I am not talking about which function does
what in the source code. I am just pointing out the current behavior
experienced (and expected) by the user.
Regards,
Ady.
More information about the Syslinux
mailing list