> 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.