Syslinux - Sep 2015 - move firmware-specific code into a directory

2015-09-20 14:21 UTC+02:00, Patrick Masotta via Syslinux <syslinux at
zytor.com>:
>>>>
>  > 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.

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

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

On that topic you may read "ifdef considered hamful" that specifically
talks about portability. It's not life-changing, but worth reading
IMO.
>
>
>>>>
>> 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.
Portability may not *be about* code organization, but IMHO, not doing
it is a way to disaster.


Celelibi

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

On 20/09/2015 20:40, Patrick Masotta via Syslinux wrote:
>>>>
>   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.
Guess:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.662

Didier