[syslinux] *.c32 for efi64 and efi32?

[Ady]

> Hi Ady,
> Thanks. I agree with you. For the short time, to focus on the real goal,
> either improving Syslinux code or by configuring DHCP/PXE. However, in
> the long term, I still suggest that proper file name extension for
> COMBOOT files is better. To me, I still do not feel comfortable that
> EFI64 arch using file name *.c32 for its COMBOOT files.
> My 2 cents.
> 
> Steven.
 
FWIW...

IMHO, seeing a "32" in a cfg or in a file name when using EFI"64" 
hardware should probably not be considered enough of a reason to 
change it (thus *forcing* users to change too). If that would be the 
case, then seeing "COM32" in a cfg file when booting BIOS-based 
x86_64 hardware might also be a problem (and this is not new). 
Another example: the UEFI specification using "BOOTIA32.EFI" instead 
of "BOOTX32.EFI".

If the "32" (or "64") would have an actual impact, then by all means. 
But the file name extension for Syslinux modules could had been 
".xyz" (or anything else), and we would have the same directory / 
naming conflict when using modules for multiple firmware. That's the 
reason we have the PATH directive; so to reduce the necessary "noise" 
when dealing with this situation.

In the cfg file, you _could_ replace "COM32" with "KERNEL" and so on. 
FWIW, I usually go the other way, replacing the generic "kernel" key 
word with the more-specific ones, "com32" or "linux", but each way 
has its merits (pros/cons).

Personally, I don't like the idea of losing the possibility of using 
relative paths in (in-)common cfg files for different firmware. In 
theory, the "relative paths" feature would still be available, but 
having to "accommodate" new file name extensions in the cfg file 
would effectively make it unusable for this purpose.

Changing the documentation and supporting users should also be 
considered.

Currently, I don't see unique nor clear advantages for this change. I 
might see a personal preference matter, and maybe an aesthetic one.

If there is a problem or a goal (such as wanting back the fallback 
searched-for paths), let's try to solve *it*.

We should look for alternative ways to configure DHCP/PXE, and/or how 
to improve the source code, so the feature (searched-for fallback 
paths) can be used again.

FWIW, I can indeed think of new features and improvements that are 
needed / desired in Syslinux (and this is certainly not new either).

Suggestions and patches are surely welcome.

Regards,
Ady.