The conditional should be checking for gnutls presence.
On openSUSE Tumbleweed without gnutls this gives me:
> ./test-tool/iscsi-test-cu --list|grep -i chap
ALL.iSCSICHAP
ALL.iSCSICHAP.Simple
ALL.iSCSICHAP.Invalid
iSCSI.iSCSICHAP
iSCSI.iSCSICHAP.Simple
iSCSI.iSCSICHAP.Invalid
Install gnutls, rebuild and check for base64 test presence:
> sudo zypper in gnutls-devel
> git clean -fxd .
<rebuild>
> ./test-tool/iscsi-test-cu --list|grep -i chap
ALL.iSCSICHAP
ALL.iSCSICHAP.Simple
ALL.iSCSICHAP.Invalid
ALL.iSCSICHAP.Base64
ALL.iSCSICHAP.Base64Oversize
iSCSI.iSCSICHAP
iSCSI.iSCSICHAP.Simple
iSCSI.iSCSICHAP.Invalid
iSCSI.iSCSICHAP.Base64
iSCSI.iSCSICHAP.Base64Oversize
Signed-off-by: David Disseldorp <ddiss@suse.de>
Some targets such as LIO support base64 encoded CHAP_R values. Test this
by intercepting hex-encoded CHAP_R responses and converting the value to
base64.
This will fail on targets which don't support base64; we should probably
skip the test instead.
base64 encoding is performed using the gnutls_base64_encode2() function,
so the test is only present for gnutls-enabled builds.
Signed-off-by: David Disseldorp <ddiss@suse.de>
libiscsi utilizes a bunch of POSIX threads functions but does
not link against libpthread as it should nor the pkg-config file
properly listing libpthread as a static link time dependency.
Add an abstraction for mutexts and threads
that handles both pthread api and native win32 api
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
libgcrypt is a relatively large dependency that is used only for
the sake of computing MD5 in the CHAP authentication protocol.
Allow distributions to disable it forcibly and rely on the
embedded MD5 implementation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Using -Wno-strict-aliasing is almost always wrong. If any code would be
introduced in the future that violates the strict aliasing rules, please
use -fno-strict-aliasing instead.
In one of recent commits the argument passed to m4_esyscmd()
macro was switched to its unescaped version. This is not correct
because package version is then defined as "Version 1.19.0"
instead of just "1.19.0".
Fixes: cb4489776b
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Instead of adding __attribute__((unused)) to unused arguments, add the
-Wno-unused-parameter compiler flag.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Since 2c1619edef61a03cb516efaa81750784c3071d10 for linux kernel and
55843c4ab8f559679d28c559cc4d681836be769b for rdma-core, rdma cma
supports RDMA_OPTION_ID_ACK_TIMEOUT. It's useful for RDMA out of
sequence case. Because this feature is added recently, we have to
check this in autogen.sh before building source code.
Depend on production enviroument, tunning rdma ack timeout could get
the best performance. Suggested by Bart and Ronnie, instead of using
a fixed timeout value, add two methods to set rdma ack timeout value.
1, add URL variable 'LIBISCSI_RDMA_ACK_TIMEOUT'. This could works
for a specified connection.
2, add env argument 'LIBISCSI_RDMA_ACK_TIMEOUT'. This works as a
common setting for all the connection of a process.
Test under different packet loss rate and different ack timeout, run
fio (iodepth=1) in a guest os, I got this result:
latency under packet loss rate 0.00001:
timeout 19: avg 170.22, pct99.9 215
timeout 10: avg 160.08, pct99.9 215
timeout 8 : avg 146.39, pct99.9 177
timeout 7 : avg 148.37, pct99.9 211
latency under packet loss rate 0.0001:
timeout 19: avg 949.23, pct99.9 306
timeout 10: avg 818.53, pct99.9 378
timeout 8 : avg 615.84, pct99.9 189
timeout 7 : avg 618.89, pct99.9 310
Base on this test report, setting ack timeout to 8(1048.576 usec) is
a good choice in my test enviroument.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Since it is easy to trigger a stack overflow with variable-length arrays,
use dynamic memory allocation instead of VLAs. Add -Wvla to the compiler
options such that no new VLAs get introduced.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
In a production system, the examples are not needed.
Add a configure option to disable building the examples.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When doing a production system, the production environment has been
pre-validated (with this test-toll or by other means), so the teest-tool
is not needed in production.
Add a configure option to disable building test-tool.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When doing cross-compilation, the tests are meant to be run on the
target. However, they are currently not installed, so it does not make
sense to build tehm to start with.
Additionally, when doing a system for production, those tests are not
needed anyway.
Add a configure option to disable building the tests altogether.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The ac_cv_-prefix variables are supposed to be settable from the command
line, à-la: ./configure ac_cv_foo=no
The canonical way of doing so is to use AC_CACHE_VAL() or AC_CACHE_CHECK().
The latter is to be preferred in our case, as it handles printing the
message for us.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
strncpy use in iscsi_reconnect is just fine. Do not warn for it, and
also do not warn if clang does not recognize the flag.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Win32 has been rotting for a while. This patch adds vs17 build files
as well as fixing up all build errors that have accumulated.
There are still build warnings but those can be addressed in a followup
patch.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Avoid that building libiscsi on a RHEL 5 system fails as follows:
configure.ac:7: error: possibly undefined macro: AM_SILENT_RULES
Avoid that the following warning is printed when building on a RHEL 5
system:
examples/Makefile.am:24: Libtool library used but `LIBTOOL' is undefined
examples/Makefile.am:24:
examples/Makefile.am:24: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
examples/Makefile.am:24: to `configure.ac' and run `aclocal' and `autoconf' again.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Avoid that autoconf prints the following warning if AM_PROG_AR
is not defined:
configure.ac:9: warning: macro `AM_PROG_AR' not found in library
See also commits 1deb4f8e4a, ace7f200fb, b9cf7e8cd2 and
6cdb47b9b4.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
These tests depends on not yet released version on TGTD to allow running
both TGTD and TGTADM as unprivileged users to set up and configure
targets to test against during make test.
Update TGTD to tip of master before running these tests.
See STGT mailinglist for patches.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
The current test in configure.ac for CUnit uses AC_TRY_RUN, which
doesn't work in a cross-compilation context, because we can't run on
the build machine the binaries that are built for the target. In
addition, the current logic assumes CUnit is available when the
AC_TRY_RUN test cannot be used (e.g in a cross-compilation case).
Since we actually don't care about *running* but only about testing
whether a simple program include the CUnit header file and linking
against the cunit library works, simply use AC_TRY_LINK() instead of
AC_TRY_RUN().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After checking several platforms, we do need this change in order to build.
If CentOS<old-version> does not manage we need to figure out why and how to fix it.
This reverts commit b9cf7e8cd2.
Linux distributions like openSUSE 12.3 include CUnit version 2.
Apparently libiscsi uses some CUnit version 1 data structures that
have been modified in CUnit version 2. This causes the libiscsi
build to fail against CUnit version 2. Fix this by detecting the
CUnit version during the configure step.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Some users and distro packagers might not want to build with -Werror,
this allows them to disable using -Werror but enables it in the default
case so as to maintain the current behavior.
