> 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
>