[syslinux] move firmware-specific code into a directory

[Patrick Masotta]

>>> 
 Hm... Maybe I'm biased by the Linux source code organization, but
 I'd rather see things like this:
 1) Keep the code in core and com32 as generic as possible and just
 call some functions that have a BIOS and an EFI implementation.
 Like com32/modules/reboot.c would call a function that is implemented
 both in arch/{bios,efi}/lib/reboot.c, and the Makefiles link as appropriate.
<<<

This is somehow already implemented i.e. by the "firmware" structure (mostly function pointers)
but it has its problems.
1) There's not a one to one correspondence between BIOS and EFI functions.
2) Having a structure with function pointers makes extremely difficult to follow the code
and know what function we are really calling on a particular situation. Debug is a real pain.
3) .c32 modules that are a simple single source file will become complex entities.


>>>
 2) Keep the use of #ifdef at a minimum.
 If all the non-portable code is kept inside the arch directory,
 that would make any non-portable module to just fail to compile.
 <<<

splitting every single c32 module like that is going to be messy...

>>>
 I think that #ifdef in the code are evil because:
 - They are quite painful to read and maintain.
 - It only get worse with time as more are added and more cases need to
 be supported that overlap each ot her.
 - For "readability" reasons, one may decide to add generic code in
 both branches of the #ifdef instead of splitting it. This may, indeed,
 make each branch more readable but duplicate the work and the number
 of potential bugs. So none of the solutions is good.
<<<

I think that the approach of a single structure (i.e. firmware) of function pointers
leads to code much harder to maintain/understand/follow/ etc, etc.
 
>>>
 On that topic you may read "ifdef considered hamful" that specifically
 talks about portability. It's not life-changing, but worth reading
 IMO.
 <<<

no link available.


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

 Portability may not *be about* code organization, but IMHO, not doing
 it is a way to disaster.

 Celelibi
 <<<
 
My humble point is let's carefully discus before to embrace any radical change
(even if it looks apparently cool).

Best,
Patrick