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.> > Perhaps there is a different (better?) way to deal with all this? > > Regards, > Ady.-- 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
> > > 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 forevery 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.
On Apr 23, 2014 5:31 AM, "Ady" <ady-sf at hotmail.com> wrote:> 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.Currently, the linker drops text strings into hdt.c32 specifying its dependencies and the Syslinux core hunts for those. It would be a change of the Makefiles and the list of filename suffixes to attempt which is already variant-specific. I believe this becomes a near-trivial development change. However, I think the bigger impact is on the user side as any scripts used to copy them around and any config files will likely change. Currently, my config files all reference COM32s with ".c32" (the preferred setup add it eliminates the filename guessing game) and I'd need to remove that to keep things universal and slow things down in the process. --Gene
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