On Fri, Oct 24, 2014 at 11:00:07PM +0200, W. Martinjak wrote:
> Are there some historical reasons or other resentements against using
> the TCP-feature in NML? IMHO this feature should be
> upgraded/expanded.
Nobody has been actively maintaining the code for NML-over-TCP, and
there aren't any automated tests of the code so we don't necessarily
know when changes introduce breakage. We don't even have a turn-key
configuration that would let a developer run with NML-over-TCP just
interactively.
In this case, it's reasonably clear that the proposed change will break
NML-over-TCP, because it does not introduce this new thing
(autogenerated globally unique serial numbers) for NML-over-TCP.
It may be the case that bug #328's attachment
"nml_tcp_user_serial_number.patch" (found in the middle of the
discussion) is very close to what is required to fix NML-over-TCP, but
for other reasons (such as the 64-bit problems, partially fixed by that
other patch from months ago where you reported positive results), Sascha
Ittner wasn't able to test and finalize that patch. (I'm really not in
a position to analyze whether it's close or not at all close)
If a developer who wanted to ensure that NML-over-TCP works asked me
what steps I thought would be effective, I would suggest
1) If it works in 2.6 (or 2.5) between two 32-bit x86 machines,
write a test of the form that goes in tests/.
Mark the test as an expected failure in conditions where it
doesn't work (such as the host being a 64-bit platform)
(I can't think of a good way to do a mixed 64/32 test in the
context of the built-in testsuite, since a particular build is
either for 32-bit systems or for 64-bit systems. But almost any
test is better than no test.)
2) assuming the test fails for 64-bit machines, figure out why,
and fix it.
As could be seen from Ebo's April patches, there are a lot of
problems in there with variables of type "long" which are of
an architecture-dependent size.
3) figure out how to fix the serial number problem in the context of
NML-over-TCP, either by cooperating with the code from #328 or by
finding a different approach to this class of bugs.
Jeff
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
