Hello Syslinux Team,
Syslinux 5.xx / 6.xx are currently showing some backward
compatibility issues. Between the ML and the IRC, there have been
some comments / reports regarding memtest, older kernels, plop boot
manager, ifplop.c32, hdt.c32... In some cases, the problems were seen
when booting with some specific variant of Syslinux 5.xx / 6.xx (say,
ISOLINUX only, or PXELINUX only); or with some brand of PC hardware.
Some of the issues indeed have led to code improvements in Syslinux
5.xx/6.xx.
If a certain image or module (say, hdt.c32 or ifplop.c32 for example)
is working OK in previous Syslinux versions, and the same image
doesn't boot as expected from a new Syslinux version (or a c32 module
from the same new Syslinux official archive fails), then we, users,
are going to be less willing to use newer versions of Syslinux
(and/or, distros will be more reticent to adopt new Syslinux versions
if they fail in some not-so-uncommon hardware).
Expecting from every kernel / image / c32 module to be adapted
according to new Syslinux versions would be unrealistic.
As already known, in Syslinux 4.xx there is a linux.c32 module,
intended to test / introduce newer features / capabilities, which are
(to be) part of the core of Syslinux 5.xx and newer.
So, would it be possible to add a new 'kernel-type' directive or a
c32 module to new Syslinux versions, so to somehow "replicate" the
behavior of Syslinux 4.xx? (Please keep reading before answering.)
If Syslinux 5.xx / 6.xx can't successfully boot an image, then this
new directive / c32 module might. This might help in finding why 5.xx
/ 6.xx can't boot such image with "standard" directives, while
still
giving the possibility of using such image with new Syslinux
versions.
There are some alternatives, such as _not_ using Syslinux 5.xx / 6.xx
:(, or chain-loading (to another boot loader or another boot
manager). But, realistically, if chain-loading is needed for this
purpose, then there would be no point in using Syslinux; just use
another boot loader / boot manager in the first place.
I understand that this idea of a new directive or a new c32 module
for this particular purpose might probably go against the direction
of Syslinux 5.xx code. I am just thinking aloud about realistic
alternatives to "the maintainer of that code / kernel / image / c32
module needs to update it".
Thank you and Best Regards,
Ady.
