[syslinux] move firmware-specific code into a directory

[Ady]

> To port a .c32 module to EFI requires a few steps:
> 
> 1) The .c32 module must have access to the gnu-efi environment; I have posted a
> patch some time ago that does exactly that (I really can't find it, surely Ady will help).
> 
> 2) based on makefile variables it is very easy to define within the .c32 source code 
> "BIOS only sections" and "EFI only sections" i.e.
> 
> ...
> 
> // BIOS and EFI code section 
> 
> #ifdef __FIRMWARE_BIOS__
> 
>    // BIOS only code section 
> 
> #else
> 
>   // EFI (32 or 64) only code section
> 
> #endif
> 
> // BIOS and EFI code section 
> ...
> 
> There will be cases where the source is going to be split in just 2 big different sections 
> with no much common code but it doesn't matter; at the end the produced binaries will 
> be located at the right place within the tree and their code will be the right one.
> 
> 3) All the code that somehow "touches" BIOS code must be replaced by EFI code.
> 
> 
> Note:
> Even when: 
>  a) An EFI compatible .c32 module must be linked against (have access to) the gnu-efi environment.
>  b) The module is loaded by an efi application i.e. syslinux.efi
> The module itself "is not" an EFI application (it does not have the EFI PE format) it remains a .c32 module,
> then it's not necessary to "chainload" to an EFI app what is not implemented in syslinux yet.
> 
> 
> >>>
> > I like the proposal of arch/{bios,efi}.
> > And because Free software is mostly do-o-cracy, please do.
> 
> > Groeten
> > Geert Stappers
> <<<
> 
> Finally:
> I think these .c32 module BIOS/EFI issues are not about code organization and I encourage
> all of us to think this very well before to either embrace radical changes on this point or to 
> encourage probably wasting lot of creative energy on a not fully analyzed problem.
> 
> Best,
> Patrick
 
 
FWIW, I would rather see efforts invested on making c32 modules usable 
under all supported firmware architectures, instead of changing the 
whole directory tree structure. Adding some kind of conditional(s) in 
Makefiles seems appropriate.

BTW, if a c32 module would be built for BIOS only and then someone 
patches the code so to make it usable under UEFI also, then the change 
in Makefiles should be simple. The code in Syslinux already requires 
skills, knowledge, and a certain learning curve; so lets not 
over-complicate matters.

Indeed, producing c32 modules under the efi32 and efi64 subdirectories 
while they are not really usable under such systems is not nice nor 
user-friendly, but lets not pretend it is the worse / most important 
issue in the current Syslinux code.

If it can be done, without making it more difficult for contributors / 
coders (especially for potential new ones), great. If it is going to 
make things more difficult for new developers to learn how the code 
works (with the intention of contributing), or if it happens to require 
too much focus / investments from the very few contributors that 
Syslinux currently has...

As I have said in past emails (among other places), current regressions 
and essential features are still the main issue for Syslinux these days 
(or rather, years). In fact, let me emphasize that statement: it is 
_the_ issue.

@Patrick (and whoever might be interested):
I have posted the link several times (even recently):

"[PATCH 0/1] EFI access from Com32 modules"
 http://www.syslinux.org/archives/2015-March/023320.html 

(and please, remember the "8.3 file name format"; TIA)

Regards,
Ady.
 
> 
> 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>