[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
> 
 
Sorry, I meant:
 PATH bios
 INCLUDE bios.cfg
 
> 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.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>