I asked before about config_cwd and after some more digging, it looks like it could be removed... Specifically, the documentation http://www.syslinux.org/wiki/index.php?title=Config#CONFIG says: ---------- * CONFIG config_file [new_WD] Load a new configuration file. The new configuration file is read, the Working Directory is optionally changed (if specified via an optional second parameter), and then the new configuration file is parsed. If new_WD is not specified, then the Current Working Directory is maintained, unchanged. The Working Directory may be different from the path to the config file. ---------- But looking at the actual code, it doesn't *read* so much as just *open* the config file. So presumably, the open() implementations (by filesystem type?) would look for the config file with a relative filename in the old current directory and not the new current directory. Is that a useful or necessary feature? Is Matt Fleming (author of the original code) still lurking on this list to explain? Or could IMAGE_TYPE_CONFIG set the directory before processing the config file. Both menu.c32 and ldlinux.EXT have parse_configs() functions that they send the argc/argv list they receive. Both functions handle multiple arguments as multiple config files to be processed (with either parse_one_config() or parse_main_config()). The documentation (http://www.syslinux.org/wiki/index.php?title=Menu#Alternative_configuration_file) shows examples of this for the menu.c32 case. But this highlights that we have two different config file parsers with different behavior. I haven't looked closely to completely confirm but, menu.c32 probably doesn't handle INCLUDE directives and LDLINUX doesn't support the "~" shorthand for config file names. What about if the CONFIG (LDLINUX) and MENU.c32 (and gfxboot.c32?) modules looked for arguments like "cwd=path/to/dir" (cwd relative and possibly including .. to drop parent directories?) or "cwd=/abs/path/to/dir" to change directories at that point in the parsing of the config files. (Similar to the way initrd=filename is special for KERNEL types) Then we wouldn't need this config_cwd private buffer and we could delete it and save some bytes of memory and simplify code. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com Changing the world through technical innovation
> I asked before about config_cwd and after some more digging, it looks > like it could be removed... > > Specifically, the documentation > http://www.syslinux.org/wiki/index.php?title=Config#CONFIG says: > > ---------- > * CONFIG config_file [new_WD] > > Load a new configuration file. The new configuration file is read, the > Working Directory is optionally changed (if specified via an optional > second parameter), and then the new configuration file is parsed. > > If new_WD is not specified, then the Current Working Directory is > maintained, unchanged. > > The Working Directory may be different from the path to the config file. > ---------- > > But looking at the actual code, it doesn't *read* so much as just > *open* the config file. > > So presumably, the open() implementations (by filesystem type?) would > look for the config file with a relative filename in the old current > directory and not the new current directory. > > Is that a useful or necessary feature? > > Is Matt Fleming (author of the original code) still lurking on this > list to explain? > > Or could IMAGE_TYPE_CONFIG set the directory before processing the config file.The CONFIG directive first changes the CWD and then it parses the new cfg file; or at least it is supposed to. For network setups, I would humbly suggest avoiding absolute paths, and using [MENU] INCLUDE (instead of CONFIG) whenever possible. FWIW, years ago (circa 2012-2014) I tested the CONFIG directive with many, many variations using ISOLINUX and SYSLINUX in several versions (4.05+, 5+,6+). Several improvements were introduced back then. If the CONFIG directive fails (now, or in the future) in SYSLINUX or in ISOLINUX, I hope someone else will step up for testing.> > Both menu.c32 and ldlinux.EXT have parse_configs() functions that they > send the argc/argv list they receive. Both functions handle multiple > arguments as multiple config files to be processed (with either > parse_one_config() or parse_main_config()). The documentation > (http://www.syslinux.org/wiki/index.php?title=Menu#Alternative_configuration_file) > shows examples of this for the menu.c32 case. > > But this highlights that we have two different config file parsers > with different behavior. I haven't looked closely to completely > confirm but, menu.c32 probably doesn't handle INCLUDE directives and > LDLINUX doesn't support the "~" shorthand for config file names.There are several parsers: CLI, [vesa]menu.c32, GFX, the Complex Menu System, and there are external parsers too. About "[MENU] INCLUDE", see first: http://www.syslinux.org/wiki/index.php/Config#INCLUDE read it and then follow the "see also" link to "Menu#INCLUDE". Although I wish for the CLI parser to support "~" too, I would not be surprised if it doesn't, even in older versions -- I haven't tested it in years. If I were to express wishes / priorities, I would rather see the long-time regressions being fixed (e.g. LSS16 background; updating dependencies such as lwip, gnu-efi, png...; dealing with pending patches...; booting optical media in UEFI mode and so on). There is a reason for so many Linux distros still using Syslinux 4.xx and older, instead of updating. Of course, it is easy to just wish and hope.> > What about if the CONFIG (LDLINUX) and MENU.c32 (and gfxboot.c32?) > modules looked for arguments like "cwd=path/to/dir" (cwd relative and > possibly including .. to drop parent directories?) or > "cwd=/abs/path/to/dir" to change directories at that point in the > parsing of the config files. (Similar to the way initrd=filename is > special for KERNEL types) Then we wouldn't need this config_cwd > private buffer and we could delete it and save some bytes of memory > and simplify code. > > Phil P. >Regards, Ady.
On Mon, Mar 06, 2017 at 03:51:07AM +0000, Ady Ady via Syslinux wrote:> > > I asked before about config_cwd and after some more digging, it looks > > like it could be removed... > > > > Specifically, the documentation > > http://www.syslinux.org/wiki/index.php?title=Config#CONFIG says: > > > > ---------- > > * CONFIG config_file [new_WD] > > > > Load a new configuration file. The new configuration file is read, the > > Working Directory is optionally changed (if specified via an optional > > second parameter), and then the new configuration file is parsed. > > > > If new_WD is not specified, then the Current Working Directory is > > maintained, unchanged. > > > > The Working Directory may be different from the path to the config file. > > ---------- > > > > But looking at the actual code, it doesn't *read* so much as just > > *open* the config file. > > > > So presumably, the open() implementations (by filesystem type?) would > > look for the config file with a relative filename in the old current > > directory and not the new current directory. > > > > Is that a useful or necessary feature? > > > > Is Matt Fleming (author of the original code) still lurking on this > > list to explain?It is a serious while ago that Matt posted on this ML, so don't wait for an answer from him.> > Or could IMAGE_TYPE_CONFIG set the directory before processing the config file. > > > The CONFIG directive first changes the CWD and then it parses the new > cfg file; or at least it is supposed to. > > For network setups, I would humbly suggest avoiding absolute paths, and > using [MENU] INCLUDE (instead of CONFIG) whenever possible. > > FWIW, years ago (circa 2012-2014) I tested the CONFIG directive with > many, many variations using ISOLINUX and SYSLINUX in several versions > (4.05+, 5+,6+). Several improvements were introduced back then. > > If the CONFIG directive fails (now, or in the future) in SYSLINUX or in > ISOLINUX, I hope someone else will step up for testing.Thing a project should learn, is proper handling the feedback from tests.> > Both menu.c32 and ldlinux.EXT have parse_configs() functions that they > > send the argc/argv list they receive. Both functions handle multiple > > arguments as multiple config files to be processed (with either > > parse_one_config() or parse_main_config()). The documentation > > (http://www.syslinux.org/wiki/index.php?title=Menu#Alternative_configuration_file) > > shows examples of this for the menu.c32 case. > > > > But this highlights that we have two different config file parsers > > with different behavior. I haven't looked closely to completely > > confirm but, menu.c32 probably doesn't handle INCLUDE directives and > > LDLINUX doesn't support the "~" shorthand for config file names. > > > There are several parsers: CLI, [vesa]menu.c32, GFX, the Complex Menu > System, and there are external parsers too. > > About "[MENU] INCLUDE", see first: > http://www.syslinux.org/wiki/index.php/Config#INCLUDE > read it and then follow the "see also" link to "Menu#INCLUDE". > > Although I wish for the CLI parser to support "~" too, I would not be > surprised if it doesn't, even in older versions -- I haven't tested it > in years. If I were to express wishes / priorities, I would rather see > the long-time regressions being fixed (e.g. LSS16 background; updating > dependencies such as lwip, gnu-efi, png...; dealing with pending > patches...; booting optical media in UEFI mode and so on). There is a > reason for so many Linux distros still using Syslinux 4.xx and older, > instead of updating. Of course, it is easy to just wish and hope.That is because wishing and hoping can everyone. Coding is a skill that requires more training.> > What about if the CONFIG (LDLINUX) and MENU.c32 (and gfxboot.c32?) > > modules looked for arguments like "cwd=path/to/dir" (cwd relative and > > possibly including .. to drop parent directories?) or > > "cwd=/abs/path/to/dir" to change directories at that point in the > > parsing of the config files. (Similar to the way initrd=filename is > > special for KERNEL types) Then we wouldn't need this config_cwd > > private buffer and we could delete it and save some bytes of memory > > and simplify code.Yes please, kill config_cwd Groeten Geert Stappers -- Leven en laten leven