On Oct 24 2014 4:18 PM, Jeff Epler wrote: > 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.
A couple of things that might work is, if possible, set up the build bot so it spaws two (or more) virtual machines and have them talk together. I have done this to test task-based computing before testing the code on a Bluegene. In this case, one VM would be 32-bit, and the other would be 64-bit, AND you could swap between the two. In addition, you could test 64-64 and 32-32 TCP-IP as well. Another option is to write the test code such that it tests the data as it goes out, or comes in, but a full functional test would be better. ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
