According to https://www.rfc-editor.org/rfc/rfc7143#section-11.15,
these are both 2-byte quantities. Loading 4-byte quantities and
passing them through ISCSI_NTOHS might have worked by accident on
x86, but it's not gonna fly on big-endian. (Fortunately sparc64 is
not just big-endian but also strict-alignment so it caught this
problem!)
XXX Is there an upstream for this code? doc/3RDPARTY doesn't cite
any easily-followed references.
PR port-sparc64/57784
XXX pullup-10
XXX pullup-9
XXX pullup-8
Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
Cherry-picked from upstream:
https://git.savannah.gnu.org/gitweb/?p=config.git;a=commit;h=1c4398015583eb77bc043234f5734be055e64bea
Everything except external/apache2/llvm/dist/llvm/cmake/config.guess
is patched, which is under vendor tag and cannot be modified. I expect
that this file is not actually used as we use hand-crafted version of
configure script instead of cmake for building LLVM.
Note that external/apache2/llvm/autoconf/autoconf/config.guess has
already been committed on Oct. 20, but commit message disappeared as
cvs aborted due to "permission denied" when trying to modify the file
mentioned above. Sorry for confusing you.
Also note that GMP uses its own config.guess Patch for
external/lgpl3/gmp/dist/config.guess is provided by ryo@. Thanks!
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
introducing since release of software to be recognised. This should hopefully
allow the builds to progress a littles further on systems such as the POWER8
which features a little endian 64-bit PowerPC CPU identified as ppc64le.
Don't use broken 48bit accesses for ISID either.
This fixes the LUN ghosting problem on big-endian systems.
LUN handling is still incorrect because it assumes a LUN value < 256
and doesn't parse the 64bit LUN for extended formats.
targets. Use this function in the initiator, to ensure that the same limit
is used throughout (i.e. stop you attempting to compile the initiator with a
different limit to the library - the initiator uses the library for most of
its functionality).
If truncating the number of targets in the initiator, truncate it to the
correct amount, not half of what it should be.
Obey RFC3720 when determining targets. SendTargets=All MUST be supported
on a discovery session, and MUST NOT be supported on an operational session.
Previously, SendTargets=All was used both in the initial discovery session
and the later session. (from Daisuke Aoyama - author of istgt).
Use relevant TargetAddress, not just first one we happen to find.
Following improvement based on feedback from Daisuke Aoyama (author of istgt):
Handle NOP-OUT CmdSN and immediate bit.
Handle NOP-IN TransferTag=0xffffffff.
Interim solution for dealing with Underflow bit in iSCSI response.
iscsi-initiator now talks to istgt and other targets.
Remaining issues:
CHAP support will not work with most targets (maximum 16 octet challenge is
used, but other initiators use up to 1024). However, CHAP can now be
bypassed by not specifying a username.
didn't work (insisted on a username being given and then used, plus always
advertised CHAP to the target). Make initiator work as advertised (i.e.
defaults to auth type none and so don't require a username).
To use CHAP you should explicitly request CHAP:
iscsi-initiator -a chap -u user -h targetname /mountpoint
For backwards compatibility, if a username is given (-u) and no auth type
is specified (-a), it will default to CHAP, i.e. to use none, just give no
username:
iscsi-initiator -h targetname /mountpoint
This means /mnt/mytarget.domain.local/target0/storage is now
/mnt/target0/storage.
Rationale is as follows:
- The hostname used may vary (i.e. name vs FQDN vs IP) which can mess up
mountpoints (especially across multiple hosts e.g. in a shared xen pool)
- Target name is given in the mount anyway so it is redundant
OK agc@
riastradh