>>>>>I do not understand.Are we parsing a configuration file and potentially >>starting new TFTP transfers while downloading it? How can we do this on >>a single thread?We cannot stop/resume a TFTP transfer then I cannot >>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >>transfer N+1 if TFTP transfer N is not finished yet, all in a single >>thread and with none of the TFTP transfers timing out. >> >>I might be wrong but I think syslinux TFTP transfers are "atomic" (they >>transfer the whole configuration file) later the parsing action on the >>received file defines if other/s TFTP+parsing actions are required in >>case the INCLUDE command was previously found. If this is correct then >>there is never more than one TFTP file transfer at any given time (and >>we could use PXEbc). >>Please let me know if I'm wrong. Thanks. >> >>Best,PatrickOn Wed, Sep 30, 2015 at 1:42 AM, H. Peter Anvin <hpa at zytor.com> wrote:> > We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary.Observing this behavior appears to be all about buffer sizing.? I had a 19 kiB config, first line a SAY, second line an INCLUDE and it loaded 13 data blocks (0-12) before delaying the ACK, loading the next file completely (0-6), and resuming the first with the ACK and loading the remaining blocks (13-15).? It still appears to be the same IO rate. Aside from potentially needing smaller buffers for config files before parsing (which seems trivial and unnecessary), what other benefits are there to this strategy? -- -Gene<<< Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. 2) We cannot implement i.e. TFTP windowsize option (RFC 7440)3) Linked timeouts; a timeout situation while downloading a nested file impacts the whole download chain. I wonder how many times this schema was responsible for random non-recoverable TFTP errors while loading conf files (specially on congested networks) leading to client reboot.4) etc. If there is not some hidden constrain (please Peter let us know) we should probably think of replacing this schema. Best,Patrick
On 10/1/2015 6:18 AM, Patrick Masotta via Syslinux wrote:> -Gene<<< > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. > Best,PatrickSpeaking utterly ignorantly here... could this switch help with the issues we see with HP systems? The load-and-hang many of them do with syslinux.efi as discussed here? E.g., maybe they implement this protocol a little better...? -Alan
> On 10/1/2015 6:18 AM, Patrick Masotta via Syslinux wrote: > > > -Gene<<< > > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. > > Best,Patrick > > Speaking utterly ignorantly here... could this switch help with the > issues we see with HP systems? The load-and-hang many of them do with > syslinux.efi as discussed here? E.g., maybe they implement this > protocol a little better...? > -AlanApologies for this slight off-topic. Who "they" would be? Let's not fool ourselves. HP _might_ solve possible issues regarding their firmware when a (current) MS OS / bootloader shows some problem for users of newish HP hardware. Let me emphasize: HP will _only_ consider publishing a firmware update under certain specific conditions, and any issue related (even loosely) with using syslinux.efi in HP hardware is not one of such circumstances. Any non-MS bootloader will probably have "disadvantages" regarding the compatibility between HP's firmware and the bootloader, simply because HP does not test any other bootloader. Back to the main topic now. Regards, Ady.> > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
>>>> Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. > Best,PatrickSpeaking utterly ignorantly here... could this switch help with the issues we see with HP systems?? The load-and-hang many of them do with syslinux.efi as discussed here?? E.g., maybe they implement this protocol a little better...? -Alan<<< It very well might. I remember your "load-and-hang"; that could be becauseHP just does not need to test their UDP4 Binding Services because bootmgfw.efi does not use that, then they might very well have a non-reported FW bug there. But how to know if it is a problem in our side or their side? who knows.. but also "who cares" is we can avoidusing EFI UDP4 Binding Services... That's why I think we should redesign the conf strategy avoiding the requirement of simultaneous TFTP transfers and stick to PXEbc like bootmgfw.efi does. On that case if we got a bugthe chances are it is just "our" fault. Best,Patrick
On 10/01/2015 05:18 AM, Patrick Masotta via Syslinux wrote:> > Aside from potentially needing smaller buffers for config files before > parsing (which seems trivial and unnecessary), what other benefits are > there to this strategy? >At the core, is that Syslinux is a general bootloader which gives access to a virtual filesystem. It supports multiple open files, but not seeking or writing. SOME of the reasons to support multiple files have gone away because of the shuffler and more comprehensive memory management, however. -hpa
On Thu, Oct 1, 2015 at 9:57 AM, Alan Sparks <asparks at doublesparks.net> wrote:> On 10/1/2015 6:18 AM, Patrick Masotta via Syslinux wrote: > >> -Gene<<< >> Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: >> 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. >> Best,Patrick > > Speaking utterly ignorantly here... could this switch help with the > issues we see with HP systems? The load-and-hang many of them do with > syslinux.efi as discussed here? E.g., maybe they implement this > protocol a little better...?Regarding HP EFI systems with issues, there's yet another way that can help syslinux.efi load ldlinux.e*, by using a timeout to turn off UseDefaultAddress. -- -Gene
>>> > > Aside from potentially needing smaller buffers for config files before > parsing (which seems trivial and unnecessary), what other benefits are > there to this strategy? >At the core, is that Syslinux is a general bootloader which gives access to a virtual filesystem.? It supports multiple open files, but not seeking or writing. <<< Please correct me if I'm wrong: Supporting multiple open files could've been done mapping the "whole" file in memory w/o requiring multiple in-progress TFTP transfers right?>>>SOME of the reasons to support multiple files have gone away because of the shuffler and more comprehensive memory management, however. ??? -hpa <<< Do you remember other reasons besides "INCLUDE" handling that today might depend on multiple in-progress TFTP transfers?Thanks, Best, Patrick