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.> ________________________________________
--
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