[syslinux] *.c32 for efi64 and efi32?

Steven Shiau steven at nchc.org.tw
Wed Apr 23 04:46:40 PDT 2014

On 04/23/2014 05:27 PM, Ady wrote:
> 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.
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 Shiau <steven _at_ stevenshiau org>
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C

More information about the Syslinux mailing list