[syslinux] When is PATH directive used?

[Ady]

> Ady asked:
> > Have you read the "See also" section(s) of the wiki page(s)?
> 
> Yes.
> 
> > By reading the relevant wiki pages, a user should (_hopefully_) get to
> > the conclusion that the PATH directive is relevant for c32 modules, and
> > not a replacement for the CONFIG / INCLUDE directives nor for relative
> > paths based on the "Working Directory".
> 
> There's nothing in Directives/path that says it applies only to c32. 
 
 
You probably mean something like "Config#PATH", which starts with:
"Specify a space-separated list of directories to be searched when 
attempting to load modules". The key part here is "to load _modules_".
 
 
> Rephrasing the first sentence on that page:
> 
>    When attempting to open a file name, the CWD is searched first, 
> before PATH.
> 
> Perhaps that should be:
> 
>    PATH is a space-separated list of path prefixes to be tried when 
> searching for a C32 module. Note that the CWD is always searched first.
> 
> Wouldn't hurt to also say:
> 
>    Note also that PATH is not used when opening INCLUDE files, or the 
> various types of KERNEL binary files.
> 
> 
> > So, no, the case you are presenting here is not a bug.
> 
> It seems PATH would be more useful if it applied to *all* loads of 
> binary files, and perhaps also to INCLUDE or perhaps a separate CFGPATH 
> directive could give places to look for configuration files.
> 
> 
 
 
The whole point of the PATH directive is to search for c32 _library_ 
modules, which are dependencies of other c32 modules. Since there is no 
absolute separation between "main" c32 modules and "library" modules", 
the PATH directive applies to all c32 modules, and only to them.

If each-and-every file were to be directly mentioned in the 
configuration file (as it used to be up to Syslinux 4.xx included), the 
PATH directive would not be needed at all. With the introduction of c32 
dependencies (aka "library modules"), there is a need to tell the main 
modules where to search for their dependencies (according to the 
directory structure that the user sets up).
 
 
> Which brings me back to my original question: any suggestion on how to 
> make "common directory distinct config" work?
> 
> Ady suggested:
> > In other words, put the c32 modules in the adequate (sub)directory, use
> > the PATH directive accordingly, and use relative paths notation in the
> > configuration file for directives other than PATH and for files other
> > than c32 modules.
> 
> This won't work, since c32 aren't the only binaries that might be 
> architecture specific. For example there was talk on this list at one 
> point of making version of memdisk for EFI. I want a single config entry 
> to load the correct memdisk depending on current running architecture. 
> If I specify the relative path to the binary, then my config is specific 
> to an architecture. If there were some kind of support to set a custom 
> variable, then I could at least do this:
> 
>   archstub.cfg:
>    SET MYARCH=bios
>    INCLUDE rest.cfg
> 
>   rest.cfg:
>    ...
>    LINUX syslinux/$MYARCH/memdisk
> 
> 
 
 
The PATH directive is not a replacement of using actual paths in the 
configuration file.

Variables is a whole different matter. Each one of these topics (i.e. 
variables in the configuration file, and modules' dependencies) is 
already less "user-friendly" and less "KISS" than what Syslinux used to 
be. Combining and interconnecting these two would be even less 
"user-friendly".
 
 
> At any rate, my impression at this point is that "common directory 
> distinct config" is not workable, when it seemed initially like an 
> attractive way to have most of the config (all but an initial stub to 
> set the PATH) be identical for both architectures. Bummer.
> 
> Thanks,
> Alex
 
 
Each approach has pros and cons. The fact that one approach doesn't fit 
your particular current needs / expectations doesn't mean it is not 
workable; just look for another approach that fits your requirements 
and leave the former approach for those users that are fine with it.


Regarding hypothetical alternatives to the PATH directive, from a 
user's perspective I would had suggested a different type of new 
directive, instead of PATH. I would had suggested different directives, 
one per platform (i.e. one per firmware's architecture), something in 
the _form_ of:
 "NEWPATH<arch_type> <my_path_for_this_arch_type>" 

in which "NEWPATH" is just a generic (starting) name for such 
hypothetical new set of directives - please forgive me for the lack of 
imagination, we could think of a better name for this hypothetical 
directive if it were to be actually relevant.

We could think of "NEWPATHBIOS" or "NEWPATH0X00", and "NEWPATHEFI64" or 
"NEWPATH0X09" for examples.

Or else:
 "NEWPATH <arch_type> <my_path_for_this_arch_type>" 

in which "<arch_type>" is the first argument of NEWPATH and the second 
argument is the actual path.

When booting in BIOS, the "NEWPATH 0X00" directive(s) would be valid 
and the others would be ignored. Similar respective behaviors would 
apply for the other platforms.

As with most Syslinux directives, the last "NEWPATH" directive (with 
the relevant <arch_type>) in the configuration file would be the only 
valid one, or perhaps we would rather have a different kind of parsing, 
such as "cumulative", or perhaps a "sticky" directive. This would need 
further debate.

This hypothetical new directives alternative would be slightly 
different than any other directive in Syslinux; but, the current PATH 
directive is already slightly different anyway.

The advantage of this hypothetical approach, from a user's perspective, 
is that it wouldn't need separated configuration files for each 
platform, whereas the current PATH directive uses separated 
configuration files and then some INCLUDE or CONFIG directive combining 
each of them with the "common.cfg". Instead, we could have three (or 
more) "NEWPATH" directives in one configuration file; or several 
configuration files as with the current PATH directive or whichever 
other combination we would prefer.


At any rate, this is all hypothetical. Regarding the current PATH 
directive, I think you have a clear answer to your question now.

Regards,
Ady.
 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>