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