[syslinux] move firmware-specific code into a directory

[Patrick Masotta]

>>>
 > This is related to bug #37.
 > http://bugzilla.syslinux.org/show_bug.cgi?id=37
 > 
 > Actually, I think this raises a more general issue about the source
 > code organization. Most of the code of syslinux has been developped in
 > a time where only BIOSes were supported. And now, there is no real
 > separation between generic code and BIOS-only code (while UEFI code
 > has its own directory). So some modules compiles for UEFI but are
 > non-functional.
 > 

 > I wonder if anyone has a knowledge of the source code general enough
 > to clarify this and move the firmware-specific code into a directory
 > arch/{bios,efi}. I personnally mostly know about the efi part.

Celelibi
<<<


AFAIK today .c32 modules are mostly BIOS only because of "historical" reasons;
so far we didn't get many coders working on expanding those modules to 
work under EFI.

As I see it, from a programmers point of view, the current organization is perfect 
for starting the porting job; virtually everything is there, we should probably
just publish a list of the .c32 modules that at the moment are "BIOS only" though.

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