[syslinux] PXERETRY directive

[Gene Cumm]

On Wed, Apr 27, 2016 at 7:55 AM, Ady via Syslinux <syslinux at zytor.com> wrote:
>
>> On Thu, Apr 21, 2016 at 10:30 PM, Ady via Syslinux <syslinux at zytor.com> wrote:
>> > Would someone please be so kind to explain / describe the PXERETRY
>> > directive?
>>
>> $ git grep -ni pxeretry
>> com32/elflink/ldlinux/readconfig.c:1305:    else if (looking_at(p, "pxeretry"))
>> com32/elflink/ldlinux/readconfig.c:1306:        PXERetry =
>> atoi(skipspace(p + 8));
>>
>> core/fs/pxe/pxe.c:275:    int i = PXERetry;
>>
>>
>> It's used in pxe_searchdir() to affect how many times it retries to
>> open a file and added in commit 4f989f247 for 4.03.
>>
>> --
>> -Gene
>
> If possible, I would appreciate some additional information, perhaps
> aimed at common users?
>
> Some of the following questions might sound strange to some readers,
> but I have found no information nor examples (nor experiences by
> others), at all, that could help describe the behavior for a common
> user.
>
> Some of the questions that come to mind...
>
> _ Does it affect the initial configuration file (e.g.,
> "pxelinux.cfg/default")? At first sight, this question might seem to
> have no sense, considering that the configuration file needs to be
> found and be parsed first, before being able to act according to the
> PXERETRY directive in it. But, as a common user, I am not sure whether
> there could be some situation in which the / a configuration file is
> re-read and/or re-parsed -- the CONFIG directive, the INCLUDE
> directive, and the config.c32 module perhaps could be relevant for this
> question.

It's a configuration directive, not a DHCP option or the ADV.  The
initial config must be read then PXERETRY changes an internal variable
during parsing.

> _ Does it affect every single file? For instance, if the user tries to
> execute a c32 module, does PXERETRY affect the command? And what about
> kernel / initrd file(s)? What happens when using pxechn.c32 or when
> loading a different network bootloader / NBP (for instance, with the
> PXE directive)?

It should, based on function placement.

> _ Does it have any effect when using (vesa)menu.c32? Could it (perhaps
> unintentionally) affect the presentation of the boot menu itself (e.g.
> by loading the menu on screen several times, according to the PXERETRY
> value)?

It affects file IO functions only on failure, not on success.

> _ Is the PXERETRY directive "sticky" (similarly to the SERIAL
> directive)? Can it be reset or changed by loading a different
> configuration file? Or perhaps, is it reset automatically after any
> particular situation / action / behavior?

It appears sticky.

> _ Is there a valid range of values? Are non-decimal values accepted?

Zero and positive integers.  It's a count.  Suggested values would be
rather low, likely in the range of 1-10.  Consider the latency
possibly incurred if a large value is used.

> _ Would I be correct by assuming this is a global directive?

Action is during parse, not execution of a LABEL.

> _ Is it valid for pxelinux.0 only? What about lpxelinux.0? What about
> syslinux.efi? Others?

Both pxelinux.0 and lpxelinux.0.  The others have the variable but no
functions that read it.

> _ Could someone please describe a usage case for this directive? Why
> might it be needed? What for? In which circumstances? Which behavior
> (or log's content) would trigger the need / desire for this directive?
> Which advantage or positive consequence(s) would it provide?

4f989f2478227c426401b27607f3f1bab7476c1c

    pxe: add a "pxeretry" option to deal with 404's in web apps

    For web downloads, sometimes a mirror site will not be fully synced.
    Add an option to retry the open a specific number of times before
    giving up.

> I wish I would have the means to actually test all these cases by
> myself, instead of asking here.
>
> I hope these questions might also trigger the curiosity of others to
> test and report back, considering that this directive is not very
> well-known.
>
> I also hope the potential replies / answers would help users to find
> this email thread as (initial) documentation for this PXERETRY
> directive, considering that it is not documented anywhere else (or at
> least, I couldn't find it).
>
> TIA,
> Ady.

-- 
-Gene