[syslinux] Problem with 90MB Initrd

[H. Peter Anvin]

I humbly thinks it has worked just fine for 15 years.  TCP works the same way, and flow control to the input buffers is an explicit design criterion for both TCP and TFTP.

On September 30, 2015 6:27:04 AM PDT, Patrick Masotta <masottaus at yahoo.com> wrote:
>>>>
>>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,Patrick
>We can, and do, suspend a TFTP transfer simply by delaying the ACK
>packet as necessary.
>-hpa
>
><<<
>I humbly think this is not a good approach. What happens when the
>transfers are made using i.e. HTTP instead?I see the costs of this
>strategy without seeing the benefits; was this done to marginally
>"simplify" thethe required editing/insertion process when the INCLUDE
>command is found?
>Do you see anything wrong on the alternative approach that i.e. would
>loop around 
>"Parsing / Downloading the whole file / Editing" 
>starting with the line "INCLUDE /pxelinux.cfg/default" ?
>Sorry for bothering you with this; I'd love to avoid the dependency on
>simultaneous transfers (specially under EFI); 
>please forgive me if I'm wrong.
>
>Best,Patrick
>
>
>
>
>
>
>
>
>
>
>   

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.