[syslinux] suggestions for global APPEND consistency

[Gert Hulselmans]

2013/2/13 Ady <ady-sf at hotmail.com>:
>
>>
>> > On Tue, Feb 12, 2013 at 3:17 PM, Ady <ady-sf at hotmail.com> wrote:
>> > > Hello Syslinux Team,
>> > >
>> > > I have some suggestions / requests regarding global APPEND commands.
>> > > These would make the behavior more consistent and more useful for
>> > > practical cases.
>> > >
>> > > 1_ Add some functionality equivalent to "APPEND -" to the command
>> > > prompt.
>> > >
>> > > 2_ Activate the functionality of ONERROR from [vesa]menu.c32 too.
>> > > Currently, ONERROR only works from the command prompt.
>> >
>> > This seems like it's a separate discussion and a possible bug.  I'm
>> > guessing you observe this when (vesa)menu.c32 is used as UI or DEFAULT
>> > with a reduced TIMEOUT.  Perhaps "ONERROR menu.c32 errmenu.cfg" will
>> > show different behavior (in which case it's likely a config error not
>> > a bug).
>>
>> Well, it is not a completely separate discussion. I observed the
>> ONERROR inconsistency while testing global APPEND. Starting from
>> menu.c32 and selecting an entry, the ONERROR statement seems to be
>> not activated (but I could be making a mistake or a wrong
>> assumption). If the same entry is tried from CLI, ONERROR acts.
>>
>> The "relation" between ONERROR and the global append tests I was
>> performing is that ONERROR "merges" its statement with the specific
>> command from the specific entry. Although this is not the same as
>> merging an alternative "global append" (which is currently not
>> possible), it was part of my tests.
>>
>> BTW, regarding the recently reported bug about running "label
>> options" from CLI... I also saw the same problem while testing global
>> append statements.
>>
>> I agree that suggestions #1 and #2 could be separated from the rest,
>> but they are all related to my experience / tests of global APPEND.
>>
>> >
>> > > 3_ Add a new directive that would function as global APPEND, with the
>> > > difference that it could be merged with specific KERNEL+INITRD+APPEND
>> > > commands (those that are used after LABEL). *Just for the purpose of
>> > > this email*, let's call it [MENU] GAPPEND (Please forgive me if using
>> > > the word "MENU" for this new suggested directive is not appropriate;
>> > > the concepts I post here are still applicable without this word, so I
>> > > will use [MENU] GAPPEND). The resulting generic command would be:
>> > > KERNEL + [MENU] GAPPEND + INITRD + APPEND (in this order). Any of the
>> > > four parts of this resulting command could be not-explicitly stated
>> > > in the cfg file.
>> > >
>> > > 4_ When pressing TAB on a LABEL in [vesa]menu.c32, the command line
>> > > should display ALL the resulting commands, including [MENU] GAPPEND.
>> >
>> > That's the trick about global APPENDs: they are always applied unless
>> > there's a different APPEND.
>>
>> My request / suggestion #4 just says that if you start from
>> [vesa]menu.c32, select an entry and press TAB, it would be useful to
>> see the full resulting command, including my suggested [MENU] GAPPEND
>> part, instead of _silently_ executing it without showing it in the
>> command prompt. To "correctly" understand my intention, suggestion #5
>> is also essential.
>>
>> This of course is not possible when you start with the prompt and you
>> manually type in the command. I hope this hints to one of the reasons
>> for me to suggest [MENU] GAPPEND as a new directive.
>>
>>
>> >
>> > > 5_ For [MENU] GAPPEND, if the resulting command is manually edited in
>> > > the boot prompt, the edition should be respected (as oppose to
>> > > silently forcing [MENU] GAPPEND).
>> >
>> > As I've stated, I feel the most useful option is to either
>> > A) remove the global APPENDs
>> > B) discourage users from using them.
>>
>> I disagree. The most useful for users, IMHO, would be implementing a
>> different directive, which I called it "[MENU] GAPPEND" for the
>> purpose of this email thread, which would behave more consistently
>> (and it is not exactly the same as the current global append).
>>
>> Suggestions #3 to #5 (plus, applying "APPEND -" to "[MENU] GAPPEND"
>> too, call it #6 if you want) are all independent of the current state
>> of global APPEND, and they act as a whole.
>>
>> Note that I am suggesting a new directive, in part so not to break
>> the current global APPEND behavior (whether the current global append
>> usage would be discouraged or not).
>>
>> TIA,
>> Ady.
>> _______________________________________________
>
>
> Let's start over.
>
> Given the potential confusion with the discouraged global APPEND
> directive, I am requesting the implementation of a new directive.
> Let's call it "MENU GLOBAL APPEND" for the purpose of this email.
>
> To try to clarify the characteristics of this request, here is a
> syslinux.cfg file:
>
>  *** syslinux.cfg start ***
> UI menu.c32
> PROMPT 1
> MENU GLOBAL APPEND /dir/
>
> LABEL ls_label
> COM32 ls.c32
>
> LABEL new_cfg_dir_label
> CONFIG new.cfg
>
> LABEL new_cfg_basedir_label
> CONFIG new.cfg
> APPEND - /
>  *** syslinux.cfg ***
>
> The above cfg file boots to CLI ("prompt 1").
>
>
> The resulting behavior should correspond to the following steps.
>
> 1_ Type "ls.c32" ; [ENTER].
>  The resulting command is "ls.c32" and it lists the content of the
> CWD.
>
> 2_ Type "ls.c32 /" ; [ENTER].
>  The resulting command is "ls.c32 /" and it lists the content of "/".
>
> 3_ Type "ls.c32 /dir/" ; [ENTER].
>  The resulting command is "ls.c32 /dir/" and it lists the content of
> "/dir/".
>
> 4_ Type "ls_label" ; [ENTER].
>  The resulting command is "ls.c32 /dir/" and it lists the content of
> "/dir/".
>
> 5_ Type "ls_label /dir/" ; [ENTER].
>  The resulting command is "ls.c32 /dir/ /dir/" and it fails, then it
> shows the correct usage of ls.c32.
>
> 6_ Press [ENTER] at the command prompt.
>  The "UI menu.c32" command from the cfg file is executed and the menu
> is displayed.
>
> 7_ Select "ls_label" ; [ENTER].
>  The resulting command is "ls.c32 /dir/" and it lists the content of
> "/dir/". Equivalent to step #4.
>
> 8_ Press [ENTER] at the command prompt.
>  The "UI menu.c32" command from the cfg file is executed and the menu
> is displayed.
>
> 9_ Select "ls_label" ; press [TAB] and then [ENTER].
>  The resulting command that is displayed and also executed is
>  ".com32 ls.c32 /dir/" and it lists the content of "/dir/".
> Equivalent to step #4.
>
> 10_ Select "ls_label" ; [TAB].
>  The resulting command that is displayed is ".com32 ls.c32 /dir/". In
> the resulting CLI, delete "/dir/", leaving ".com32 ls.c32" only.
> Press [ENTER]. The resulting command is ".com32 ls.c32" and it lists
> the content of the CWD. Equivalent to step #1.
>
> 11_ Press [ENTER] at the command prompt.
>  The "UI menu.c32" command from the cfg file is executed and the menu
> is displayed.
>
> 12_ Select "new_cfg_dir_label" ; [ENTER].
>  The resulting command is "CONFIG new.cfg /dir/".
>
> 13_ Reboot. Press [ENTER] at the command prompt.
>  The "UI menu.c32" command from the cfg file is executed and the menu
> is displayed.
>
> 14_ Select "new_cfg_basedir_label" ; [ENTER].
>  The resulting command is "CONFIG new.cfg /".
>
> (Note: If more examples of the desired behavior are needed, I can
> provide them for clarification. Just ask.)
>
>
> The characteristics of this requested new directive should be:
>
> A_ It merges the statement with specific KERNEL+INITRD+APPEND
> commands (those that are used after LABEL). The resulting generic
> command would be the concatenation of:
>  KERNEL + MENU GLOBAL APPEND + INITRD + APPEND (in this order).
>
> B_ Any of the four parts of this resulting command could be
> not-explicitly stated in the cfg file.
>
> C_ When pressing TAB on a LABEL in [vesa]menu.c32, the command line
> should display ALL the resulting (concatenated) commands, including
> MENU GLOBAL APPEND, in the mentioned order:
>  'KERNEL' 'MENU GLOBAL APPEND' 'INITRD' 'APPEND'
>
> D_ If the resulting command is manually edited in the CLI, the
> edition should be respected (as oppose to silently forcing any
> additional command). WYSIWYG. Note that using a 'label' as a command
> responds exactly the same from CLI or from menu.
>
> E_ The usage of "APPEND -" in a label entry should override merging
> the MENU GLOBAL APPEND statement with the specific commands of that
> entry.
>
> F_ It should be possible to combine the "APPEND -" with additional
> label-specific commands too, as shown in "new_cfg_basedir_label" in
> the above syslinux.cfg file. As I am not a developer, I am not sure
> whether this characteristic is achievable by this exact expression.
> Yet, the final intention of this characteristic is quite clear.
>
> G_ MENU GLOBAL APPEND shall NOT affect UI nor DEFAULT directives.
>  If "DEFAULT mylabel" is used, then MENU GLOBAL APPEND would affect
> the resulting command according to the statements in the 'mylabel'
> entry, just as if 'mylabel' were to be selected. If "DEFAULT
> mycommand" is used, then MENU GLOBAL APPEND has not effect in the
> resulting command.
>
>
> The above characteristics should make this new suggested directive
> consistent with other directives and uses in [vesa]menu.c32 and in
> CLI.
>
> I hope this time I am making my request more clear. This email could
> potentially have a different subject title, unrelated to a global
> append. I just left it "as-is"
>  so to provide an initial context for this request.
>
> TIA,
> Ady.
>
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

Instead of all this global append stuff, it would be better to have
variable support in Syslinux for this kind of thing:

 *** syslinux.cfg start ***
UI menu.c32
PROMPT 1
VARIABLE $standard_kernel_options=a lot of kernel parameters you want by default

LABEL 1
LINUX bzImage
INITRD initramfs
APPPEND $standard_kernel_options

LABEL 2
LINUX bzImage
INITRD initramfs
APPPEND $standard_kernel_options some extra options

LABEL 3
LINUX bzImage
INITRD initramfs
APPPEND no standard kernel options but user only the parameters
explicitly given on this append line
*** syslinux.cfg ***

Then you can explicitly specify where you want to have some default parameters.

When Syslinux parses the config file it should first get all
"VARIABLE" variable lines and
replace all variables in the whole config file. Then it should parse
this in memory config file
with the expanded variables again (it can skip the VARIABLE lines now).

So when editing LABEL 1 from the menu, the user should only see:
  .linux bzImage initrd=initramfs a lot of kernel parameters you want by default

And not:
  .linux bzImage initrd=initramfs $standard_kernel_options

Variable support could then also be used for non append lines (like
the path to the kernel image).

- Gert