[syslinux] Module Versioning

[Ady]

> On 2/24/2016 22:55, Shao Miller wrote:
> > Suppose... [...]
> > ...that we embed such a version in Syslinux core and in all OS 
> > programs and modules.  Maybe even with some nearby magic so that a 
> > "whichver" command can examine and answer.
> >
> > If we have that, Ady's recent question is: If Syslinux' module-loader 
> > encounters a module without version-info, do we:
> > - Reject and return
> > - Warn and continue
> > - Hope for the best and continue
> >
> > ?
> 
> I'm still interested in feedback about this.
> 
>    boot: some.c32
>    Warning: COMBOOT32 module version unknown
>    Hello from some.c32
>    boot: another.c32
>    Warning: COMBOOT32 module version mismatch
>    I'm another c32
>    boot: website.c32 Shao Miller
>    https://www.synthetel.com

 
 
Let's analyze the different options you proposed.

1_ Reject and return.

Whether a module includes version information or not, the "reject" 
alternative sounds too-restrictive to me.

If a module were to be compatible with the bootloader even with a 
version mismatch - it could still happen - I wouldn't like to restrict 
the user just because of a technicality.

In other words, I'd rather have the freedom to try, instead of being 
blocked / not allowed from the starting point.

There is one case in which "rejection" might be more effective than 
anything else: firmware mismatch. For instance, if the user boots a 
BIOS-based bootloader of the Syslinux family (i.e. ldlinux.c32), then 
there is no chance to have any successful result when a UEFI_x64 module 
is executed. Another example: if booting with "ldlinux.e32" 
(UEFI_ia32), then trying to execute a binary file (module) that was 
built for UEFI_x64 (or for BIOS, for that matter) would be worthless. 
But, a module that has no version information at all is not part of 
such scenario; we simply don't know which is the intended firmware's 
architecture of the module.

I do want to add that, if rejecting, then the output should include 
some kind of information before returning to the boot prompt (or to any 
other mode). In other words, this option would be "reject, inform, 
return". Rejecting without providing information to the user would 
generate more problems than it would solve, IMHO.


2_ Warn and continue.

Whether a module includes version information or not, the "continue" 
part allows the freedom I commented about for option #1.

About the "warning" part... If I understand correctly, this means that 
before executing the module, the "version" is checked (against the 
version of the bootloader / ldlinux.*). If there is no kind of mismatch 
/ conflict, I think that there should be no warning / info; i.e. the 
module should be executed as it has been done up to this point, with 
the user not having to note any difference.

Now, what if there is a "version" mismatch... The "warning" part seems 
to have at least 2 matters for further discussion.

First, will the "version checking" make the process slower in any 
noticeable manner? Are we going to make the process slower for everyone 
in any case?

Should we have some directive defining the behavior(s) (with multiple 
possibilities that could be combined, as SYSAPPEND)? I am thinking 
about someone that do not want nor need the version checking, so a 
directive (or rather, its value) would indicate "don't bother me, don't 
waste time checking for potential version mismatch, I know what I'm 
doing, my files came from the same build of Syslinux". In such case, 
the default (i.e. this hypothetical new directive is not present in the 
cfg) would be to indeed perform the version checking.

I am not saying this is the best default behavior for such directive, 
and perhaps the default behavior should be to maintain backward 
compatibility status (i.e. no checking of versions, unless the cfg 
includes this directive with a specific value). As I said, this would 
need further discussion.

My second point regarding the "warning" part is, what would exactly be 
the output? Should we support "text / graphic /serial" (similarly / as 
in "DLE..ETB" / "Ctrl-P..Ctrl-W" / "ASCII 16..23")? Should there be 
some additional directive defining a timer, so to display the "warning" 
before returning back to boot prompt? Or instead we would leave this 
behavior as any other warning we already have in Syslinux? How the 
current TIMEOUT directive affect the behavior (both, when present, and 
when TIMEOUT is not included in the cfg)? Or perhaps the "warning" 
timer should be a fix value in the code, with no possibility for the 
cfg to affect it?


3_ Hope for the best and continue.

What I am understanding by this option is that we would include some 
(optional?) version information in c32 modules, but we would leave any 
checking for users, with no influence / change to the boot process. 

Users might need to check the version of each module they would be 
interested in (or have doubts about, or that are part of some 
troubleshooting, or...) outside the Syslinux boot environment. Even a 
raw HEX viewer might be such tool, without any explicit command of any 
kind being included in the Syslinux archives. Or perhaps each module 
should have a "--version" argument.

I think the first step would be to develop the necessary fields for a 
"version" to be included in modules (including firmware's architecture, 
release / pre-release / built from some git commit / official upstream 
or downstream / ...), in a coherent consistent expandable manner.

Then the official modules would be patched so to include this "fields" 
of information, in a coherent consistent expandable manner.

Once we get to such point, we are in effect in this option #3. Whether 
we have some command line tool for checking the version of modules, or 
a "--version" argument for each module, or whether users would need to 
use some HEX viewer or some "grep" or similar, or whether we add the 
version-checking possibilities to the boot environment (as options #1 
or #2 in this email thread), these all might be a future additional 
development.

The question would be, if at some point we want / need either option #1 
or #2, do we need to consider such potential future right now, when 
developing these "fields" of version information? Or, is it something 
that we could develop 
independently, at a later time, currently disregarding such potential 
needs?

Regards,
Ady.