[syslinux] [PATCH 0/2] Do not use the "red zone" on EFI

Ady ady-sf at hotmail.com
Sat Nov 28 11:44:02 PST 2015

> > The addition of the EFI_BUILD variable inside Makefiles could potentially
> > affect scripts such as package builders, perhaps even the way the
> > official (pre)release archives are built(?).
> This variable is not something you're supposed to see or use when
> building Syslinux.
 Read again the commit I referenced.
> I kinda have the feeling that according to you, no commit shall ever
> be made again because it may have an interaction with the user /
> maintainer.
Your kinda of feeling is wrong.
> Maybe some users rely on the presence of the bugs. Who knows? The
> difference between a bug and a feature is pretty subjective after all.
This case is neither a feature nor a bug. Whichever parameters the 
Syslinux Team state that the make command should accept and/or support, 
the code should work as intended. Once there is a certain way to do 
things (i.e. how the code interacts with users or with other code), 
breaking backward compatibility (even for some good reason) is not just 
a simple plus; there will be negative consequences.

Improving code is a good thing, but it is not a goal by itself. The 
goal of whichever code should be for the resulting binaries to be 
usable. When a new code breaks backward compatibility, there should be 
a very good reason, and clear communication is very desirable in such 
case. If, for instance, packages fail to be built, the improved code is 
not usable.

I am not even sure this patch actually breaks the prior intended usage 

There are many distros with building scripts based on certain things 
that have been working in a certain way in the Syslinux code for 
several years. And there are many distros (some of them, very 
influential ones) in which Syslinux-related code has no maintainer. 
Breaking backward compatibility will break some of the resulting 

I am hoping all patches will _actually_ help and improve the result. By 
"result" I don't mean the official binaries in some future release 
(whenever / if it might happen); that's just one of the many 
intermediate steps.
> >
> > For further details and explanation, see the commit "The make files have
> > undergone changes to support both i386 and x86_64 platforms" (2012Jun):
> >  repo.or.cz/syslinux.git/commit/38e58635d3868c23537fc5dce87b152a52df34ad
> >
> > Perhaps we should consider how to improve the Makefiles without
> > potentially breaking backwards compatibility?
> The way I think the Makefiles could be improved is by rewriting them
> from scratch in a non-recursive way.
If you think so, please, go ahead. Please try to not break backward 

Alternatively, there might be some other known issues that deserve a 
higher priority / attention. Anyway, Freedom.
> > PS: Shouldn't this type of things (as described in the aforementioned
> > commit from 2012Jun) be included in "./doc/building.txt" and in the
> > corresponding wiki page?
> Why should they?
Because there have been enough questions during the years asking how to 
build under specific conditions certain specific binary files; e.g. 
cross-compiling, or building while the working directory is not the 
root of the source code, or building just a couple of binaries, or... 
Again, read the commit I referenced in my prior email.

I am not against improvements. I hope patches are found helpful, 
including this one, sooner rather than later.
> Celelibi

Let's see new commits being pushed, known issues being solved, ASAP.


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

More information about the Syslinux mailing list