Previously, stinit returned zero even if it fails to set the options.
This patch changes the return value to one if one or more of the options
can't be set for a device if the tape numbers are given on command line.
If no numbers are given, stinit returns zero (as before this patch).
After this change, scripts (udev rules) can more easily detect when
stinit fails.
Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
Add code to set/clear the MT_ST_NO_WAIT option bit for MTSETDRVBUFFER.
The string used in the user interface is 'weof-no-wait'.
Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
This is a trivial bug, but a bug nevertheless. It's present in the
first commit in this (synthetic) Git repository, and from my
investigations into very old versions - mt-st-0.5 from an old RedHat
version - it was already present in the `stinit.c` version from Apr
11, 1998, which makes it 25 years and 9 days old. This is a new record
for me, which I don't think I'll beat :)
The bug is trivial, in retrospect, and was found just by accident
because with the 1.6 release uploaded in Debian, the new test suite is
run on multiple architectures. While amd64/x86 doesn't trigger this
bug in neither '-O2' nor '-g' build, mips64el, arm64, and s390x do
show the bug in the optimised builds (and only in them) as follows:
amd64:
```
$ /sbin/stinit -v -v -v -p -f ./tests/data/bad-definition.data
Parsing modes for ('XYZ', 'UVW1', '').
Mode 1 definition: blocksize=
Warning: errors in definition for ('XYZ', 'UVW1', ''):
blocksize=
Definition parse completed. Errors found!
```
s390x:
```
$ ./stinit -p -v -v -v -f tests/data/bad-definition.data
Parsing modes for ('XYZ', 'UVW1', '').
Mode 1 definition: blocksize=
Warning: errors in definition for ('XYZ', 'UVW1', ''):
�H
Definition parse completed. Errors found!
```
And shelltest fails to parse that binary output, in 4/5 cases, which
by luck caused the builds to fail. From there it was a fun
investigation into trying to find why it behaves like that.
This bug is caught by the recently introduced MSAN build in the GitHub
CI, so will rely less on luck in the future.
I'm not 100% sure on the semantics of the fix, but it should only
affect this case (missing value to argument), so should be a well
localised fix.
Signed-off-by: Iustin Pop <iustin@k1024.org>
shelltestrunner was already installed for the coverage target, but not
for main test ones (for the same reason that release 1.5 was broken,
in the sense that it was not needed…).
The shelltest migration was done in 1.4, but not completed - the
distcheck was still doing hard-coded manual tests, and as such, the
"check" target from the dist archive was not working. Sigh.
Now 'distcheck' is using 'check', and the archive is complete.
I spent 20 minutes trying to understand why lcov/gcov were complaining
about wrong coverage format/version, before I saw I had a 2 year old
file that was not overwritten nor removed…
Switch to more recent versions of the checkout and codecov action, the
latter also removing saving the data locally, so remove the archival
of that data.
The embedding of tests in the Makefile works only for that is there
today - a few `--version` and `stinit -p` calls. For expanding the
test coverage, as much as it can be done for `mt`, let's use a proper
shell test runner. `shelltestrunner` is available in Debian/Ubuntu, so
it's likely to be available in other distributions too, and as such
should not be a big barrier to contribution.
This needs lcov installed, but it's a good quick helper for local
runs. For history and pull requests, codecov keeps tracking.
Also tweak in the process gitignore to clean the noise.
This is the exact same mini-"tests" that are used in distcheck, but
separated so that the tests can be run with coverage tracking. Would
be good not to have duplicates - maybe use make check inside the
distcheck?
While fixing #14, what pointed me to check parsing validity (and not
local issues as I thought at first) was that `-v -v` was showing empty
mode definitions, despite claiming parse success. So let's add a test
that mode parsing does do things, not just empty claims.
The GCC in xenial is old (5.x), and something seems to trip it
compared to the clang build, when checking the default options, see
https://travis-ci.org/iustin/mt-st/jobs/597087158.
Switch to bionic which has GCC 7, which is recent enough.
Left-shifting of negative values is undefined behaviour according to
the C standard, because it depends on the exact representation. This
code, copied from the Linux kernel, is intended for 2's complement and
can be replaced by well-defined behaviour: ~(-1<<N) is equivalent
to (1<<N)-1.
Signed-off-by: Iustin Pop <iustin@k1024.org>
Right now stinit ignores leftover chars in strings such as '9a'; let's
make sure we don't miss these (at least the warning message might give
a hint)..
