Dear Serge,
> grub2 is a part of this system, so EFI boot should not be a problem.
> The only issue with submitting all this stuff back in DL source control
> is backward compatibility which I cannot guarantee ( with reasonable
> time contribution).
I know that EFI boot is possible not only via Syslinux, but also grub2efi.
However, one of the most important features is the ability to load the same DL
system from a different drives or partitions using one of the multiple copies
of the configuration. Free choice of boot partition is allowed in Syslinux
using chain module (without changes in BIOS/EFI setup settings). This is
especially valuable on routers operating in a remote location, which are
experiencing a malfunction of hard drive or flash memory. In addition, only
Syslinux gives you the ability to indicate the number of I/O port of serial
console (eg, 16550A), which allows remote access to the full boot process
through Intel AMT. These are the reasons why I tried to fight with Syslinux EFI.
Boot the system by the BIOS or EFI Compatibility Support Module solves the
problem, as long as the producers did not decide to follow an interesting
target market for motherboards with EFI without CSM. And on this occasion I
tried to explore Syslinyx EFI.
The second problem is the security issues (eg security hole gets procedure),
which was finally cut by the C11 and what is implemented in glibc 2.16. I
thought that after over a year of C11, most packages will be revised and so I
tried once with gcc 4.7.2 and glibc 2.16. However, from a certain point, as
you noticed, almost every package need to patch in sources or in a build
script. When I came to the keepalive packet, I lost motivation for this
Sisyphean labor and I decided to put off my work for a few months. Also
because incorporated now a lot of patches will oblige us to remove them, when
authors will have his packages adapted to the new environment.
The Syslinux authors motivate us to gcc 4.7 glibc 2.16. But on the other hand
- Syslinux EFI does not fully work yet - there are problems with the modules
c32, and they are the most valuable. This is yet another reason to wait. I
think the move to EFI without CSM has not in danger us at least a year. The
scope of last update work in DL indicates that Heiko thinks the same.
> at this moment I have 2 working build environments ( the current is gcc
> 4.6.3/glibc 2.15, the former is gcc 4.5.2/glibc 2.12) which I will be
> happy to share.
>
> The both toolchains are well-tested and stable, however they are not a
> truly DL, because it was necessary to add a lot of patches to scripts
> and sources.
I'm curious, what benefits arise from the transition to gcc 4.6.3 glibc 2.15 -
because it is still in front of the standard C11. Maybe your work is near
compatible with 4.7/2.16?
Best regards in New Year
Andrzej Odyniec
|
