> On Thu, 18 Dec, at 07:47:18PM, Ady wrote:
> > I have a question about the PATH directive. In fact, the question is
> > not about how it is currently working, but about its intention or
goal,
> > or how it was supposed to work (or how it was thought about for the
> > 5.00 release).
> >
> > Previous discussions about the PATH directive in the Syslinux Mailing
> > List, and its documentation (e.g. "PATH rules") left on me
the
> > impression that it was intended for the Library Modules (only?).
>
> Yes, the original intention was to make it possible to load module
> dependencies where the module and its dependency didn't live in the
> same directory.
>
> > While testing the PATH directive with Syslinux 6.03, I can see it is
> > not only working for Library Modules, but also for other c32 files
too.
> > If a c32 file is not found according to the relative path used for it
> > in the configuration file, then the referenced c32 file is
searched-for
> > according to the PATH directive.
> >
> > So, was the PATH directive supposed to search for Library Modules
> > (dependencies) only? Or for any c32 file? Or for any file whatsoever
> > (e.g. kernel, initrd, memdisk,...)?
>
> It only works for .c32 files, but no distinction is made between a
> module and its dependencies. All .c32 are "ELF modules".
Thank you. Believe it or not, this clarifies a lot, as the "PATH
rules"
documentation is currently not clear enough about it. Now we can
improve the documentation, and perform some tests.
>
> > And, for files referenced in the configuration files (i.e.
> > non-dependencies files) using absolute notation paths, was the PATH
> > directive supposed to search for them too? (If this last question is
> > not clear enough, I'll post an example; please let me know.)
>
> Yes, the PATH directive is used as a fallback if the file denoted by an
> absolute path doesn't exist.
>
> If the file *does* exist at the absolute path, the directories in PATH
> are not searched - absolute paths take priority.
So, my first (still incomplete and still inaccurate) attempt to write
some rules about the PATH directive, and ask about remaining doubts!...
The search (for c32 files) is supposed to respect the following rules:
1_ The search for c32 files is performed according to the following
rules. The search for each required c32 file is stopped once the first
matching file name is found; remnant potential paths are not searched
(even if the execution of the firstly-found c32 file fails in some way;
e.g. unmatching version, unmatching firmware architecture).
2_ Every required c32 file starts a new search (for itself); i.e. once
a c32 file is found, if additional c32 (dependency) files are also
required then each c32 file triggers its own new search, according to
all these rules.
3_ When the c32 file is explicitly referenced by an absolute path, the
explicitly-referenced c32 file is search-for in such location first.
4_ When the c32 file is explicitly referenced by a relative path, the
explicitly-referenced c32 file is search-for in such location first,
where the base for the relative path is the Current Working Directory.
(Note: this is not the same as searching in the CWD itself.)
5_ If the CONFIG directive was used so to change the Working Directory,
then the _prior_ Working Directory is no longer relevant; only the
*Current* Working Directory is considered as base for relative paths
where the c32 files are searched-for. The (new) CWD takes precedence
over any PATH directive.
6_ After the relevant aforementioned paths, the paths stated in all the
parsed PATH directives are searched-for, one-by-one until the file is
found, in the same order as they are stated in the parsed configuration
files. Note that all paths referenced in PATH directives are parsed as
*absolute* paths, even when they are not explicitly written with a
starting slash symbol ("/").
7_ If the CONFIG directive was used, the paths in prior PATH directives
are still valid, and they take precedence over new PATH directives. In
other words, newly-parsed PATH directives are appended after
previously-parsed PATH directives (the new ones do not replace prior
ones). Once a configuration file was parsed:
7.1_ there is no method to "reset" the PATH directive.
7.2_ there is no method to eliminate a path already stated in the PATH
directive.
7.3_ there is no method to alternate the order in which the paths
stated in PATH directives are searched-for.
7.4_ all aforementioned "PATH rules" (starting from rule #1) are
re-evaluated, according to the new CWD.
8_ These "PATH rules" apply for almost every-and-any c32 file, except
for "ldlinux.c32". Other types of files (such as configuration files,
kernels, initrd, memdisk,...) are only searched-for according to the
paths being used in their respective lines in the Syslinux
configuration file, or according to the paths used in the boot command
prompt; i.e. if non-c32 files are not found in the firstly-expected
location, no additional searching is performed for such files.
And now, the current remaining doubts!!!:
D1_ Matt Fleming said:> Yes, the PATH directive is used as a fallback if the file denoted by
an absolute path doesn't exist.
D1Q: When using an *absolute* path and the c32 file is not found in
such location, is the CWD expected to be searched as first fallback for
the *explicitly-referenced* c32 file, before searching according to the
PATH directive(s)? Note that I am not asking about the c32 dependency
files, but about the explicitly-referenced one(s) (e.g. not about
lib*.c32 files but about "/some/absolute/path/menu.c32").
D2_ For this doubt I will use an example:
UI some/relative/path/menu.c32
Whether typed in CLI or parsing a configuration file, note that this is
a relative path *based* on the CWD, but not the CWD itself.
The "PATH rules" as documented in the official Syslinux 6.03
distribution archives state that the CWD is "always" searched-for
first, before the PATH directive(s). This statement (and the example
included in the official Syslinux v.6.03 documentation) clarifies the
expected behavior for paths written in absolute notation. But...
D2Q1: In the case I am presenting here (c32 module explicitly
referenced in relative notation but not referenced to be located in the
CWD itself), if menu.c32 is not found first in the referenced
directory:
<CWD>some/relative/path/
then, is "menu.c32" supposed to be searched in the CWD *itself* too
(before the PATH directive paths)? Note that I am not asking here about
the non-referenced c32 files such as lib*.c32.
D2Q2: In the case I am presenting here (c32 module explicitly
referenced in relative notation but not referenced to be located in the
CWD itself), in which locations are the c32 *dependencies* of
"menu.c32" searched-for and in which order (before searching according
to the PATH directive)? Are its *dependencies* searched-for in
"<CWD>some/relative/path/"? Are its *dependencies* searched-for
in the
CWD (too)?
D2Q3: Could the search for each of the c32 dependencies be different in
each case, according to, or depending on, where the *prior* c32 file
was found (e.g. hdt.c32, or libutil.c32, before searching for
libcom32.c32, or libmenu.c32, or..., all so eventually hdt.c32 will
load and work)? Or, instead, is each search fully independent of the
result of the prior (library) c32 file that have been just
searched-for?
D3Q1: I know that in the CLI there is no equivalent to the PATH
directive, but the PATH *rules* are still valid in the command prompt,
right? Are still _all_ the rules valid? Are there any differences?
D3Q2: Are there any *different* "PATH rules" for the boot prompt,
whether using (typing-in) relative paths or absolute paths notation?
D4_ When typing in the boot prompt, we know that the ".c32" file name
extension is used as fallback. For example, (IIRC) if I type in the
boot prompt:
ls
then Syslinux will try to find such file name (or label), "as-is"
("ls"). If such exact file name (or label) is not found in the
expected
location, then Syslinux tries to find "ls.c32" in the same location.
D4Q1: Are any "PATH rules" applied to such "fallback" file
name,
"ls(.c32)"?
D4Q2: Are any "PATH rules" applied to the dependencies of such
"fallback" file name, "ls(.c32)"?
>
> --
> Matt Fleming, Intel Open Source Technology Center
>
Matt, my goal is to improve documentation and to be able to test
whether
Syslinux actually behaves as expected regarding to the PATH rules. I
would
appreciate if these doubts could be clarified (and if I made/make a
mistake or
inaccuracy, please correct me), so the PATH rules' documentation can be
improved.
Thank you in advance,
Ady.