Syslinux - May 2013 - [syslinux:firmware] ldlinux: use platform filename extension

On 05/16/2013 03:18 AM, syslinux-bot for Matt Fleming
wrote:
> Commit-ID:  2bd94fb6ed5f7f7472319cd6adaa25ccf9819230
> Gitweb:    
http://www.syslinux.org/commit/2bd94fb6ed5f7f7472319cd6adaa25ccf9819230
> Author:     Matt Fleming <matt.fleming at intel.com>
> AuthorDate: Thu, 16 May 2013 10:16:17 +0100
> Committer:  Matt Fleming <matt.fleming at intel.com>
> CommitDate: Thu, 16 May 2013 11:01:55 +0100
> 
> ldlinux: use platform filename extension
> 
> Users are starting to package all Syslinux versions on one boot medium
> and are running into problems because all versions of ldlinux have the
> same filename, ldlinux.c32. The version of ldlinux.c32 compiled for bios
> will not work with efi32 or efi64, and vice versa. What we need is a way
> for the Syslinux core to know exactly which filename to load.
> 
> Use the following extensions for the corresponding platforms,
> 
>   .c32 - bios
>   .e32 - efi32
>   .e64 - efi64
> 
> Now all ldlinux variants can be kept in the same directory without
> causing any conflicts.
> 
> Signed-off-by: Matt Fleming <matt.fleming at intel.com>
> 
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?

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?

	-hpa

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