[syslinux] *.c32 for efi64 and efi32?

[Ady]

> 
> 
> On 2014/4/23  12:54, Ady wrote:
> > Is this about not liking the need for (sub)directories (depending on
> > firmware)? Or is it about functionality?
> >
> > If I understood correctly the prior email threads, the (real) problem
> > was in trying to maintain the searching for:
> >
> > pxelinux.cfg/01-88-99-aa-bb-cc-dd
> > pxelinux.cfg/C000025B
> > pxelinux.cfg/C000025
> > pxelinux.cfg/C00002
> > pxelinux.cfg/C0000
> > pxelinux.cfg/C000
> > pxelinux.cfg/C00
> > pxelinux.cfg/C0
> > pxelinux.cfg/C
> >
> > with the new DHCP/PXE configurations proposed by Daniel. But maybe I
> > got it wrong (?).
> Yes, the thread is about that. However, the file name extension *.c32 
> for EFI64 also confuses people. Therefore by requesting *.e64 for EFI64 
> COMBOOT files could solve these 2 issues.
> 
> Steven.
 
OK then, so let's review the situation a little more accurately.

_ Goal: to be able to keep searching for:

pxelinux.cfg/01-88-99-aa-bb-cc-dd
pxelinux.cfg/C000025B
pxelinux.cfg/C000025
pxelinux.cfg/C00002
pxelinux.cfg/C0000
pxelinux.cfg/C000
pxelinux.cfg/C00
pxelinux.cfg/C0
pxelinux.cfg/C

or some similar paths (perhaps depending on firmware type? or under 
sub-directories?)

_ The usage of sub-directories according to each firmware for 
Syslinux is not the real problem.

_ The usage of more-complex DHCP/PXE configuration(s) is not the real 
problem.

_ The DHCP/PXE configuration(s) proposed by Daniel might not be the 
only way, and perhaps there are other/better ones.

_ In the same way that one user would like to have all 
Syslinux-related files together under the same directory, other user 
might like to have a separated (sub)tree of (sub)directories, 
depending on firmware, so they can be managed independently. Both 
users might think that "his way" is more organized (or "better").

_ There might be a need to introduce improvements to Syslinux 6.xx so 
to achieve the real goal (so to get back the older functionality of 
fallback paths being searched-for, according to MAC address and/or 
firmware).

Now, let's consider some of the (other) implications of your 
proposal, i.e. using different file name extensions depending on 
firmware. (Note: as I am not a developer, please forgive me for 
potential inaccuracies or mistakes. My intention is only to present a 
general idea / argument.)

Currently, a Syslinux module that requires another Syslinux Library 
module to work looks for its (full) name. For instance, hdt.c32 looks 
for several lib*.c32 modules so to be able to work. The searched-for 
paths start at the Current Working Directory, and then potentially 
continues according to the PATH directive.

A new (as suggested) "hdt.e64" would need to look for "lib*.e64", and 
equivalent file name extensions would be required depending on each 
supported firmware. This would mean (kind of) "multiplying the source 
code". The searched-for (full) file names would no longer be the 
same; they now would change for each firmware. In other words, the 
source code (for each and every module) would vary / depend on 
firmware, instead of programming "the same source code" to generate 
all modules.

>From the point of view of the user, Syslinux configuration files for 
every firmware other than BIOS would need a review. Currently, by 
means of relative paths and the PATH directive, the same 
configuration files can (potentially) be (re)used for every firmware. 
This is not necessary, but it is currently a possibility.

But if the same directory would be used by all Syslinux modules 
(while using different file name extensions), then it would require 
editing the configuration files according to different file names, 
and/or using different file names for the Syslinux configuration 
files themselves.

Eventually, all the documentation would need to be changed. Although 
the official Syslinux documentation is not completely current, there 
are indeed efforts to update it.

The reason for the ldlinux.* module to be able to use different file 
name extensions according to the firmware is because only the initial 
steps of the boot loader (which already varies according to firmware) 
needs it. Generally speaking, EFI allows to have multiple EFI 
binaries under the same directory. The user doesn't make any 
reference to the "ldlinux" module in any configuration file. The 
other Syslinux modules depend on the "lib*" Syslinux Library modules, 
so each Syslinux module needs to know the exact (full) file name of 
its dependencies and where to look for them (by means of the CWD and 
the PATH directive).

It seems to me (and I could certainly be wrong) that varying the file 
name extension of each and every Syslinux module depending on the 
corresponding firmware has many implications, and it would probably 
require more resources from The Syslinux Project than what it would 
be realistically available / attainable.

I would tend to think that focusing on the real goal (regaining the 
fallback paths feature), whether by improving the Syslinux code or by 
configuring DHCP/PXE in a different way, might be a more effective 
way of solving the issue.

Regards,
Ady.