[syslinux] When is PATH directive used?

[Alexander Perlis]

 >> There's nothing in Directives/path that says it applies only to c32.

 > You probably mean something like "Config#PATH" [...]

No, I really did mean Directives/path, which is the first link in the 
"See Also" under PXELINUX-Multi-Arch. At any rate, it appears that page 
has been edited within the last couple days, and the new contents are 
well-written and clearly explain how PATH works. Thank you.


 > Regarding hypothetical alternatives to the PATH directive, [...]
 > I would had suggested different directives, one per platform
 > (i.e. one per firmware's architecture), something in the _form_ of:
 > "NEWPATH<arch_type> <my_path_for_this_arch_type>"

This is a very sensible suggestion! Regarding the name, simply 
PATH<arch_type> should work. As you point out, with such a directive 
available, we wouldn't need separate architecture-specific starting 
configs that use INCLUDE to pull in the rest; we could just have a 
single master config that works for all architectures:

   PATHBIOS syslinux/bios
   PATHEFI32 syslinux/efi32
   PATHEFI64 syslinux/efi64
   UI vesamenu.c32
   INCLUDE graphics.cfg
   ...
   LABEL firstentry
   MENU LABEL Menu Entry
   KERNEL ...


 > As with most Syslinux directives, the last "NEWPATH" directive
 > (with the relevant <arch_type>) in the configuration file would
 > be the only valid one

That would be good enough for my needs.


 > or perhaps we would rather have a different kind of parsing,
 > such as "cumulative", or perhaps a "sticky" directive.

Although I am a fan of flexibility, is there an example configuration 
setup that would truly benefit from this, a configuration that without 
this feature would have to be a lot more complicated?


 > Regarding the current PATH directive, I think you have a clear
 > answer to your question now.

Yes. Thank you.

I'm still not sure yet how to handle architecture-specific non-c32 
helper binaries like memdisk but the matter is moot until an EFI version 
exists and anyhow I myself am using memdisk presently only to invoke 
virtual DOS floppies containing Dell firmware flash updaters and haven't 
yet had to deal with how manufacturers might distribute firmware updates 
for EFI systems.

Which brings up another point: it may be useful to have a directive to 
restrict a menu entry to certain architectures, e.g.,

   LABEL someentry
   MENU LABEL Some EFI-only entry
   MENU ARCH efi32 efi64
   KERNEL path/to/efi-only/kernel

and a menu will be skipped (not displayed) if it doesn't match the 
architecture.


Easy to stand on the sidelines and suggest new features... a round of 
gratitude to the developers who think about the suggestions and have the 
time and skill to implement them!

Thanks,
Alex