[syslinux] config_cwd can be killed?

Geert Stappers stappers at stappers.nl
Sun Mar 5 22:12:16 PST 2017


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


More information about the Syslinux mailing list