[syslinux] Backward compatibility

Ady ady-sf at hotmail.com
Tue Jul 9 12:56:51 PDT 2013

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 

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 

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,

More information about the Syslinux mailing list