[syslinux] move firmware-specific code into a directory

Celelibi celelibi at gmail.com
Sun Sep 20 09:00:37 PDT 2015


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


More information about the Syslinux mailing list