> 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? > > > CelelibiFor 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. 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. I am not against changing code, but, as common user, I differentiate between "internal-only" code and code that "interacts" with users. I don't know how much this particular suggested change is necessary / desired, and of course I don't know how much it would potentially affect third-party tools / users; these comments are more general than this particular email thread. Example: the "simple" change (since Syslinux v.6.xx) of the location of binary files (such as "mbr.bin") by moving them to the "bios/" sub-directory tree has had a clear impact on third-party tools and distros; most common users (and more-than-one developer / maintainer of third-party tools / packages) have a negative view / opinion regarding this change of directory. BTW, let's not forget the existence of the "diag/*" files in Syslinux. Regards, Ady. 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. 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.
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
> > > > 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. > >Well, the Perl script _is_ shipped in the official release, and the change we are referring to is a command line parameter, which means it is part of the way a "user" (which I am using here as a generic term, not necessarily a final non-developer physical individual) interacts with the code. I also added, more than once, the general scope of my comments, as opposed to taking the very specific case of this particular Perl script. Reading the complete email (for context) is relevant.> > > > 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. >The example I gave (moving the location of binary files) could also be included in such category; after all, the location of binary files in prior versions is "legacy" too, and it doesn't affect the compilation of the new resulting version. And yet, it had (and still has) a clear impact on "users" (and by "users" I don't just mean final users, but rather package maintainers, other scripts, common users, and more).> > 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. >My "PS" in my prior email is/was not directly related to the Perl script, nor to the specific patch (thus, it was written after my signature, as a "PS"). It was about the generation of the "*mbr*.bin" files (which is the goal of the Perl script in question). Mentioning those projects is a way of inviting the potential investigation (by developers) of alternative ways of delivering MBR (and VBR) files and their installers in Syslinux.> > > > 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.The current installers include "ldlinux.*", which makes the them version-dependent. If the "real" installation code were to be separated, and the "ldlinux.*" files were to be arguments of such hypothetical alternative command line installer(s), we could have installers that could be independent of the version. It could simplify several situations / use-cases (while making other cases more complex), and in some cases it could even reduce the resulting size for users -- incidentally, I wrote about this matter in irc #syslinux just a few days ago. Again, this was part of a "PS", not directly related to the original patch.> > 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.The interaction with (other) code / users, either within or outside of The Syslinux Project, is the relevant point I was trying to make. This seems to be one of those different points of view between developers and users (including maintainers of packages and of generic installation methods in several distros); we see things with a different perspective.> > > CelelibiRegards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >