[syslinux] Comments WAS: Refactor checksize.pl

Celelibi celelibi at gmail.com
Thu Nov 19 22:15:50 PST 2015


2015-11-19 21:22 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:
>
>> 2015-11-19 17:30 UTC+01:00, Nicolas Cornu via Syslinux
>> <syslinux at zytor.com>:
>> > - Remove padsize argument as it is never used.
>> > - Add an usage printed when $file is not set or --help, -h
>> >   is the first argument.
>> > - Add basic tests for this script.
>> > ---
>> >  mbr/checksize.pl      | 27 ++++++++++++++++++---------
>> >  mbr/checksize_test.sh | 22 ++++++++++++++++++++++
>> >  2 files changed, 40 insertions(+), 9 deletions(-)
>> >  create mode 100644 mbr/checksize_test.sh
>> >
>
>> Just to make sure: the goal of the shell script is to check the perl
>> script?
>> If so, I wonder if it wouldn't be better in the test directory if it
>> is needed at all. I'll let the others comment on that.
>>
>> I agree with your simplification of checksize.pl, but have you
>> searched through the history to see if there wasn't a good reason to
>> separate maxsize and padsize?
>>
>>
>> Celelibi
>
> For what my personal opinion might be worth...
>
> I don't like the idea of changing "UI" (e.g. command line options that
> might be used by some users) without very well-thought reasoning.

This is not an UI. AFAIK, this script is not shipped to the user. I
don't even see what a user could do with it.


>
> In the particular case of "padsize" vs. "maxsize" (options / parameters
> of the Perl script), there used to be a separate use of them. Although
> there _seems_ to be no use for having both of them simultaneously at
> this time _for a normal build of Syslinux_, we cannot discard /
> disregard the possibility that some script in some distro might want to
> take advantage of each of them independently, especially for some
> debugging situation (e.g. some buggy / old BIOS).
>
> Another potential (hypothetical) use-case might be some "bootable USB
> tool" making use of some/many/all parts of the Syslinux code. Let's not
> forget that some distros are still using older versions of Syslinux
> (even v. 3.xx), and (unnecessarily) changing command line options makes
> the updates (unnecessarily) more difficult, generally speaking.

Keeping some legacy in the compilation chain for a potential usage
we're not even aware about seems a bit insane. If someone play with
the syslinux's internal compilation process, he is probably aware that
it may change completely on every single commit. We just do not
support this usage.

> PS: Let's also not forget the existence of other methods / code to
> generate / install MBRs and/or VBRs such as:
>  _ "sys.com" / "sys.exe" (v.3.8) from FreeDOS;
>  _ "sys-freedos-linux";
>  _ "ms-sys" ( _code in C_ ) and its forks such as:
>   _ "ms-sys-free" (current latest code is older than its parent);
>   _ a fork of "ms-sys" by Pete Batard (used in RUFUS) with additional
> recent patches.

These projects are completely unrelated to syslinux. Should someone
use our checksize.pl, he would probably copy it to his repository. As
I said, this script isn't shipped to the user. The only purpose of
this script compared to the standard command "truncate" is that it has
several default size recorded depending on the file name pattern and
fail if the file is already too large.

>
> Common users and third-party scripts might rather use the Perl script
> for simplicity, so having scripts available is helpful. Having code
> written in C for the generation / installation of MBRs / VBRs might be
> (at least in part, or as a first step) an alternative to the generation
> of the current syslinux / extlinux installers, and/or eventually an
> alternative installation method.

This script just extend the file to the size of the boot sector and
fail if it's too large. Nothing more. It has very little to do with
the installers.

Don't try to invent new use cases or new goals for the Syslinux
project.We provide a set of boot loaders and installer for those boot
loaders. Not a set of tools to help people make their own boot
loaders.


Celelibi


More information about the Syslinux mailing list