[syslinux] PATH directive
Ady
ady-sf at hotmail.com
Tue Jan 13 11:18:33 PST 2015
> 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
>
More information about the Syslinux
mailing list