[syslinux] [syslinux:firmware] ldlinux: use platform filename extension

[Matt Fleming]

On Thu, 16 May, at 06:55:54AM, H. Peter Anvin wrote:
> The more I think about it the more I am thinking this really is a bad
> idea.  Too many config files including the .c32 suffix, as unfortunate
> as it is.  I guess we could do something magic if we see a filename with
> a .c32 suffix and are on a non-BIOS platform, but does that make sense?
 
ldlinux.* is loaded before we parse any config files. This commit
doesn't apply to all .c32 modules, just ldlinux.*, which is special
anyway. This isn't a flag day change where everyone is going to have to
update their config files to no longer reference *.c32.

My plan was to add macro support so things like the following would do
the right thing,

   PATH /boot/syslinux/$PLATFORM/bin/:/more/files/

where $PLATFORM would be a built-in macro that expands to "bios",
"efi32" or "efi64". In fact, I've got a first implementation of this
working.

We have this unfortunate chikcken-and-egg problem with ldlinux.c32 -
because it contains the config file parser we need to be able to load it
before we can parse the PATH directive.

> I'm starting to think, instead, that we should pre-initialize the path
> to include a directory with a full system description before the current
> directory, maybe i386-pc i386-efi x86_64-efi.  In the compressed modules
> branch I added support for that information in the header, that way we
> can give more useful error messages at least.
> 
> What do you think?

Pre-initialising the path forces a file hierarchy scheme upon users on
top of the ones we already have. If we're only pre-initialising the path
so we can find ldlinux.*, that's probably not a big deal, but I don't
think we should be using this path for all .c32 files, if that's what
you were implying?

-- 
Matt Fleming, Intel Open Source Technology Center