[syslinux] move firmware-specific code into a directory
Patrick Masotta
masottaus at yahoo.com
Sun Sep 20 11:40:32 PDT 2015
>>>
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
More information about the Syslinux
mailing list