[syslinux] PATH directive

[Ady]

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