>>> > > 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
On Fri, Oct 02, 2015 at 12:23:18PM +0000, Patrick Masotta via Syslinux wrote:> On Thu, Oct 01, 2015 at 03:07:43PM -0700, H. Peter Anvin via Syslinux wrote: > > 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. > > 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. > > Do you remember other reasons besides "INCLUDE" handling that today > might depend on multiple in-progress TFTP transfers?Thanks, > > Best, > PatrickPatrick, Visit http://www.syslinux.org/archives/2015-October/024342.html Next the archive version of this message, which _might be_ http://www.syslinux.org/archives/2015-October/024344.html And start using an e-mail programm that blends in better with the discussions you are in. At least change your e-mail quoting style. Cheers Geert Stappers Moderator of the Syslinux Mailinglist in an attempt to get better formatted e-mails -- What was the last time you did something the first time?
Background images come to mind. On October 2, 2015 5:23:18 AM PDT, Patrick Masotta <masottaus at yahoo.com> 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. ><<< >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-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>>Do you remember other reasons besides "INCLUDE" handling that today >might depend on multiple in-progress TFTP transfers?Thanks, >Best, >PatrickBackground images come to mind. -hpa <<< Got it; but background images are always uninterrupted transfers right? I'll try to see how difficult this change might be; if you remember some other point to consider please let us know. Best,Patrick
> <<< 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? >>>The following comments will be dismissed (or ignored) by some readers (or even by many of them), with qualifiers such as "irrelevant" (or possibly worse). One of the characteristics of Syslinux that is valued by common users is its simplicity (yet still powerful) in the configuration syntax. One other characteristic of Syslinux that has been appreciated by common users during the last couple of decades (or so) is low requirements. For storage devices, the needed space has been climbing up since version 5; yet the minimal RAM requirements are still around the tens-of-KiB in order of magnitude. Considering that I am not a developer, when I read things like 'mapping the "whole" file in memory' I fear that the minimal RAM requirements could be (eventually) disregarded (too). I hope for RAM requirements to be always kept as minimal as possible, around the same order of magnitude as they have been for years. Or at least, always empower the user with options. Regards, Ady.
>>>> <<< 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? >>>The following comments will be dismissed (or ignored) by some readers (or even by many of them), with qualifiers such as "irrelevant" (or possibly worse). One of the characteristics of Syslinux that is valued by common users is its simplicity (yet still powerful) in the configuration syntax. One other characteristic of Syslinux that has been appreciated by common users during the last couple of decades (or so) is low requirements. For storage devices, the needed space has been climbing up since version 5; yet the minimal RAM requirements are still around the tens-of-KiB in order of magnitude. Considering that I am not a developer, when I read things like 'mapping the "whole" file in memory' I fear that the minimal RAM requirements could be (eventually) disregarded (too). I hope for RAM requirements to be always kept as minimal as possible, around the same order of magnitude as they have been for years. Or at least, always empower the user with options. Regards, Ady. <<< Your concern is valid;We are talking here about configuration files; they are usually pretty small.I consider at the end, the assembled conf file (after adding all the included files)it is roughly the sum of all the conf files. Then having each conf files fully "mapped" before the corresponding editing process should not change the final memory requirement by much. Best,Patrick