[syslinux] PATH directive

[Ady]

Thank you for your reply.

> On Fri, 02 Jan, at 02:23:48AM, Ady wrote:
> >  
> > Hmm, I thought it was decided to consider the colon (":") character as 
> > deprecated, and instead we should be using a space character as 
> > separator for the PATH directive (or multiple lines). Well, at least as 
> > for the current MASTER HEAD, Syslinux 6.03.
>   
> Are you referring to commit 1945579 ("PATH: use a linked list
> internally")? Looking at the code in master, it appears as though the
> colon character is still the separator.
>   
 
Yes, I was referring to that commit. I wouldn't say that ":" is "the" 
separator. Even if a colon character is still "acceptable", I thought 
it should be treated as the lowest preference among the other 
alternative options (multiple PATH directives with one path per line; 
or a space character as path separator), considering the potential 
problems (discussed in this Syslinux Mailing List) that lead to that 
commit. In other words, I thought we should reduce the use of ":" for 
the PATH directive as "acceptable for now, so to not break potential 
backward compatibility, and in some future release it might/could be 
considered as not valid anymore". Am I wrong?

> > > 
> > >   /boot/absolute/path/to/my/file.c32
> > >   /foobar/absolute/path/to/my/file.c32
> > > 
> > > Which is totally bogus, and contrary to what "absolute path" means.
> > > 
> > > I've created the following bug report to track this issue,
> > > 
> > >   http://bugzilla.syslinux.org/show_bug.cgi?id=58
> >  
> >  
> > Was/is this behavior really undesired?
>  
> Yes, we need to provide users with some method of specifying absolute
> paths, i.e. regular file system semantics.
> 
 
I understand that the paths used in the PATH directive are supposed to 
be treated as absolute paths (as per your own explanations since the 
PATH directive was introduced). What I don't understand is the reason 
to be treated _exclusively_ as absolute paths. To be clear, I am not 
claiming that it should be treated differently; but only that I am not 
sure that there is no place (or use-case) for some kind of relative 
path for the PATH directive. Users/members with more experience with 
network booting mixed firmware's architectures might have some input.
 
> > And, what _should_ had been the correct behavior?
>   
> Quoting from http://en.wikipedia.org/wiki/Path_(computing),
> 
>  "Systems can use either absolute or relative paths. A full path or
>   absolute path is a path that points to the same location on one file
>   system regardless of the present working directory or combined paths. As
>   such it must always contain the root directory."
> 
> > For paths (in a cfg or in CLI) other than in the PATH directive: any 
> > path not prefixed with a slash character (nor with a colon character, 
> > indicating a TFTP root) is to be parsed as relative to the CWD. But...
> > 
> > For the PATH directive (only), the following (alternative) lines:
> > 
> >  _ PATH some/path
> >  _ PATH /some/path
> >  _ PATH some/path/
> >  _ PATH /some/path/
> > 
> > tested separately / independently (not together / not simultaneously / 
> > not in the same boot attempt), seem to be treated all as an absolute 
> > path (if I remember my old tests correctly, but please don't trust my 
> > memory).
>  
> I'd really need to see an example config file to understand what's going
> on here.
> 
 
# The CWD is not the root of the booting fs (not "/").
# e.g. the CWD is "/boot/syslinux/".
#
PATH some/dir/other/than/the/CWD
# Note that the PATH directive is intentionally 
#  using a path expressed in relative notation.
#
LABEL lslabel
# Note that the label is different than the name of the c32 file.
#
COM32 ls.c32
# The ls.c32 file should _not_ be present in the initial CWD.
# The ls.c32 file should indeed be present as:
#  "/some/dir/other/than/the/CWD/ls.c32"
#
# Note that I am referring now to the absolute path, 
#  whereas the PATH directive in this example 
#  is intentionally expressed with a relative notation.

What I am saying is that, IIRC, the above example should show that the 
PATH directive is parsing:
 "some/dir/other/than/the/CWD"
(relative notation)
as:
 "/some/dir/other/than/the/CWD"
(absolute notation)
and I am also saying that it makes sense to ignore such potential 
user's "mistake", considering that the PATH directive only accepts (for 
itself) absolute paths anyway.
 
> > Then the statement that "the CWD is *always* searched-for first" is 
> > inaccurate.
> > 
> > The statement (as included in the official documentation) seems to be 
> > directed to c32 dependencies, but then this is one of the reasons why 
> > the PATH rules _seemed_ to be relevant for c32 dependencies only. Since 
> > the PATH rules apply to all c32 files (not just c32 dependencies), then 
> > the wording for the PATH rules should account for each-and-all cases, 
> > not just for dependencies.
> > 
> > From users' perspective...
> > 
> > The statement might be accurate for c32 *dependencies*, but not as much 
> > for explicitly-referenced c32 files (because it seems to depend on the 
> > way the c32 file is referenced; in absolute or relative notation). 
> > Which means that the other statement, "all c32 files are treated 
> > equally, whether they are dependencies or not", is also not 100% 
> > accurate.
> > 
> > So I have to go back to a prior question: what _should_ be the adequate 
> > behavior? 
> > Do we want the same (or a different) behavior(s) for 
> > explicitly-referenced c32 files comparing to c32 dependencies?
> > Do we want a different behavior for explicitly-referenced c32 files 
> > depending on the type of path notation?
> > Do we want the same behavior for explicitly-referenced c32 files 
> > independently of the type of path notation?
>  
> We want to align with the expected POSIX semantics of file system paths.
> If you do not prepend your path with a "/" on UNIX systems, it's taken
> as relative to your current working directory.
> 
> At the moment the ELF linking code specifies dependencies using relative
> filenames in the ELF headers.
> 
> > So my first attempt to write a complete set of PATH rules failed (plus, 
> > we have a bug and I am not sure what the correct behavior should had 
> > been).
> > 
> > If I understood correctly, the behavior of the c32 *dependencies* (WRT 
> > to the PATH directive / rules) is not influenced by the path notation 
> > of the explicitly-referenced file; but these questions are also about 
> > the behavior of those explicitly-referenced c32 files (WRT to the PATH 
> > directive / rules).
>   
> Dependencies *are* influenced by the usual path notation, there's
> nothing special about dependencies.
 
No, they are not, because dependencies are not explicitly referenced by 
any path. This is why the expression "c32 _dependencies_ are always 
searched-for first in the CWD before searching them according to the 
PATH directive" seems adequate, whereas the expression "*all* c32 
*files* are always searched-for first in the CWD..." is inaccurate.

Since the official documentation about the PATH directive only mentions 
c32 dependencies (the same as the included example in the "PATH RULES" 
section), there is no way for a common user to clearly understand that 
the PATH directive is relevant for all c32 files (not only for 
dependencies).

The fact that the new bug #58 is discovered only now, after more than 2 
years of the introduction of the PATH directive, suggests that 
(naturally) the focus was on c32 dependencies (and not on the 
explicitly-referenced c32 files).

An adequate documentation of the PATH directive (and, evidently, its 
functionality) is critical for booting alternative architectures.

For example:
PATH bios
INCLUDE bios

would work as expected for booting multiple mixed firmware's 
architectures only if *all* c32 files are affected by the PATH 
directive (as it is the case in v.6.03, but it is not clearly 
understood from the official documentation). If a user misunderstands 
(from the current official documentation) that only c32 dependencies 
are affected by the PATH directive, there is no way such user would 
arrive to the above cfg example as usable for booting multiple mixed 
firmware's architectures.

This example is a basic one. What would happen if the user wants/needs 
to add more complex paths such as multiple directory-levels, CONFIG 
directives changing the CWD, and a mix of relative and absolute 
notations? I was trying to understand how all such cases work, so to be 
able to test them and document them for common users.

Of course, since now we know there is a bug, there is no point (for me) 
in testing all these cases. In addition to the need to solve the bug 
(anyone out there with the necessary knowledge to solve it?), the 
current (v.6.03) documentation of the PATH directive is not 
clear/complete enough for common users.

Additionally, in past months I have proposed here some idea(s) that 
could help in some multiple-architectures scenarios. In those prior 
emails I referred to storage media, but considering later questions and 
reports, I think network booting can use similar concepts so to provide 
useful alternative solutions (e.g. multi-arch network booting setup 
with reduced needs for dhcp options). If/when active development gets a 
new push, I'll gladly bring up the proposal(s) again.
 
>   
> -- 
> Matt Fleming, Intel Open Source Technology Center
> 

TIA,
Ady.