> Running shellcheck on kernel/time/timeconst.sh produces the following > warnings: > > shellcheck kernel/time/timeconst.sh > > In kernel/time/timeconst.sh line 11: > local i=1 j=0 > ^-- SC2039: In POSIX sh, 'local' is undefined. > > > In kernel/time/timeconst.sh line 20: > local i="$1" j="$2" k > ^-- SC2039: In POSIX sh, 'local' is undefined. > > > In kernel/time/timeconst.sh line 34: > local i > ^-- SC2039: In POSIX sh, 'local' is undefined. > > > In kernel/time/timeconst.sh line 44: > local i=0 j > ^-- SC2039: In POSIX sh, 'local' is undefined. > > > > Will this cause an issue for people running posix shells? > Which shells have you tested your script on ? While local is not part of POSIX, it is widely supported, including by dash, and is used by many shell scripts in the kernel's build including link-vmlinux.sh, however I can easily make the script work without local by using unique variable names in each function and resetting all of them at the beginning of the functions if that is desired instead of local. > > Furthermore, I fear this conversion may not be suitable at present, as > it produces potentially different results for CONFIG_HZ < 100 > > (There may be more diffs, but I haven't yet compared a larger search space) > > using a quick script I put together to compare the output of > timeconst.sh and timeconst.bc for a given CONFIG_HZ: > > > https://gist.github.com/kbingham/76e8718df7b7dc97361405cc1801a160 > > > $ for i in `seq 0 300`; do ./check-timeconst.sh $i; done > > produces a diff on almost every value 2 - 243 > > http://paste.ubuntu.com/p/wNggrfFZXB/ > > Or rather 137 faults to be exact: > > for i in `seq 0 250`; \ > do ./check-timeconst.sh $i; \ > done | grep -- "--- BC" | wc -l > > > I think that might be considered a blocker to this implementation, or > those values and the impact should certainly be investigated thoroughly. > > I haven't looked into detail into the change of any of those values, so > I can not ascertain which one is more correct (though I suspect it's > likely to be bc that will have the 'more correct' value) > > I would fear doing this in shell just isn't going to maintain the > correct precision, which is likely a strong reason why bc was selected > in the first place. > > > If you can find the issue that causes this diff in your shell > processing, and clarify or fix it - then it might be possible to gain > some backing to the implementation, but even then it might become a > shell specific precision issue ... That definitely is a blocker, I will attempt to make this implementation match the bc script for those values.
