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

On Sun, Sep 20, 2015 at 06:32:48AM +0200, Celelibi via Syslinux
wrote:
> 2015-09-20 0:04 UTC+02:00, Gene Cumm via Syslinux <syslinux at
zytor.com>:
> > On Sat, Sep 19, 2015 at 4:32 PM, BALATON Zoltan <balaton at
eik.bme.hu> wrote:
> >> On Fri, 18 Sep 2015, Gene Cumm via Syslinux wrote:
> >>>
> >>> No.  pxechn.c32 is BIOS only for now.
> >>
> >>
> >> Why are there binaries of non-working components in the
distribution?
> >> This is confusing for us not knowing syslinux so well. Is there a
> >> list of files somewhere that are known not to work despite being
> >> distributed?
> >> Is there a way to not include these binaries to avoid confusion?
> >
> > No one has spent the time to prevent some of the COM32s from being
> > built on EFI architectures by working on the Makefiles.
> 
> 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.
I like the proposal of arch/{bios,efi}.
And because Free software is mostly do-o-cracy, please do.

> Anyway this would be a large change conflicting with most pending
> patches.
So be it.
I mean: Choose high level design improvement above outstanding patches.
(and I think we, the Syslinux project, have a backlog of patches
due fear of changing "too much" (yes, I say: What has to be done
has to be done ))

> Not sure it's gonna happen anytime soon.
Which makes it only harder.

There should no fear for breaking what is allready broken.






Groeten
Geert Stappers
-- 
Leven en laten leven
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: signature.asc
Type: application/pgp-signature
Grootte: 836 bytes
Omschrijving: Digital signature
URL :
<http://www.zytor.com/pipermail/syslinux/attachments/20150920/4a95aead/attachment.sig>

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

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

> 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
 
 
FWIW, I would rather see efforts invested on making c32 modules usable 
under all supported firmware architectures, instead of changing the 
whole directory tree structure. Adding some kind of conditional(s) in 
Makefiles seems appropriate.

BTW, if a c32 module would be built for BIOS only and then someone 
patches the code so to make it usable under UEFI also, then the change 
in Makefiles should be simple. The code in Syslinux already requires 
skills, knowledge, and a certain learning curve; so lets not 
over-complicate matters.

Indeed, producing c32 modules under the efi32 and efi64 subdirectories 
while they are not really usable under such systems is not nice nor 
user-friendly, but lets not pretend it is the worse / most important 
issue in the current Syslinux code.

If it can be done, without making it more difficult for contributors / 
coders (especially for potential new ones), great. If it is going to 
make things more difficult for new developers to learn how the code 
works (with the intention of contributing), or if it happens to require 
too much focus / investments from the very few contributors that 
Syslinux currently has...

As I have said in past emails (among other places), current regressions 
and essential features are still the main issue for Syslinux these days 
(or rather, years). In fact, let me emphasize that statement: it is 
_the_ issue.

@Patrick (and whoever might be interested):
I have posted the link several times (even recently):

"[PATCH 0/1] EFI access from Com32 modules"
 http://www.syslinux.org/archives/2015-March/023320.html 

(and please, remember the "8.3 file name format"; TIA)

Regards,
Ady.
 
> 
> 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>