> 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. > > -- > -GeneIf 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. _ 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)? _ 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)? _ 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? _ Is there a valid range of values? Are non-decimal values accepted? _ Would I be correct by assuming this is a global directive? _ Is it valid for pxelinux.0 only? What about lpxelinux.0? What about syslinux.efi? Others? _ 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? 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.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
> > > 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. > > _ 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)? > > _ 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)? > > _ 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? > > _ Is there a valid range of values? Are non-decimal values accepted? > > _ Would I be correct by assuming this is a global directive? > > _ Is it valid for pxelinux.0 only? What about lpxelinux.0? What about > syslinux.efi? Others? > > _ 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? > > > 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. >Anyone?
On Thu, May 05, 2016 at 06:30:30PM +0300, Ady via Syslinux 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. > > > > _ 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)? > > > > _ 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)? > > > > _ 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? > > > > _ Is there a valid range of values? Are non-decimal values accepted?From http://www.syslinux.org/archives/2016-April/025149.html What is a recommend value for the directive? Has it a default value?> > _ Would I be correct by assuming this is a global directive? > > > > _ Is it valid for pxelinux.0 only? What about lpxelinux.0? What about > > syslinux.efi? Others? > > > > _ 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? > > > > > > 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. > > > > Anyone?Please elaborate where PXERETRY was encountered, so we known which documentation peace needs additional information. (yes, that is like http://www.syslinux.org/archives/2016-April/025147.html ) Groeten Geert Stappers -- Leven en laten leven
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
> > _ 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. >Thank you very much. This is the first time I read about a directive that is usable under BIOS but not under UEFI. Is ./com32/elflink/ldlinux/readconfig.c only for BIOS? TIA, Ady.