< jeremyrubin>
FYI there seems to be some issues with s390x testing
< jeremyrubin>
WHere can I even get a s390x mainframe? Who the heck is using that
< sipa>
you can get a free shell account on some ibm site
< luke-jr>
jeremyrubin: I think the point is to have a BE build, not so much for the s390x
< sipa>
yes of course
< sipa>
it's the only BE platform on travis
< sipa>
afaik
< jeremyrubin>
oic
< wumpus>
right, testing on BE can find some cases of implementation-defined / undefined behavior that we missed, the specific architecure doesn't matter
< wumpus>
(thoug hhaving an actual CPU is nice, isntead of emulation, which is too slow to run the entire test suite in time for CI)
< luke-jr>
too bad Linux doesn't support BE binaries on LE kernel
< luke-jr>
though perhaps it'd be possible to do KVM on ppc64le -> BE
< wumpus>
indeed, some architectures potentially support switching LE/BE between processes but Linux definitely doesn't support this
< wumpus>
yes maybe with virtualization
< wumpus>
while the python side is waiting for bitcoind to finish something <- this is true, but it's still somewhat surprising because you'd expect at least one thread of bitcoind to be busy 100%, otoh, it might also be waiting in turn for I/O or such
< luke-jr>
hmm
< luke-jr>
can qemu do user-mode virtualisation? lol
< wumpus>
I just mean, the python script waiting for things to complete doesn't in itself mean that the tests are not CPU intensive
< wumpus>
user mode virtualization, heh
< wumpus>
paravirtualized system calls
< luke-jr>
well, it does system-mode virtualization, and user-mode emulation..
< wumpus>
I doubt it would be impossible but also that someone bothered to do this :-)
< luke-jr>
I'm better user-mode virt is a missing area
< luke-jr>
betting*
< luke-jr>
I wonder if it would be less work to just make Linux support either endian
< wumpus>
even user mode qemu (pure emulation) has problems with endianness and system calls
< wumpus>
converting endianness between the emulated process and the kernel more or less works but there are some surprises, with deeper-buried structures, it's a very difficult problem to do it complete
< luke-jr>
so probably less work to add to Linux <.<
< wumpus>
(e.g. even some kernel-generated proc/sys files contain binary data with native endian, so something reading it compiled for another endian will expect its own endian but finds the host's)
< wumpus>
yes maybe
< wumpus>
nevertheless it would be a huge change
< wumpus>
whole-system virtualization is much less complex becuase the paravirtualized APIs and emulated devices have a smaller API surface then system calls (or sometimes they are defined to be one endianness that can't be swithed)
< luke-jr>
of course, there's also another layer deep: stuff like Box86 which emulates the program and wrap-translates calls to the libraries <.<
< wumpus>
interesting, didn't know that project
< luke-jr>
I think it doesn't even try to mess with endian differences
< luke-jr>
IIRC it won't even cross the 32-bit/64-bit differences
< wumpus>
it looks similar to the WINE approach though for linux-linux, emulating things at the library level not the deepest system call level
< wumpus>
32-64 bit bridging is another thing that sounds easy but is a horrible mess in practice :)
< wumpus>
it's definitely relevant now that distro's are stopping shipping 32-bit libraries (though it's generally easy enough to install them in a chroot, if they keep the kernel support)
< luke-jr>
also if they keep a 32-bit userspace build :p
< luke-jr>
Ubuntu seems to have dropped that too
< wumpus>
it doesn't have to be from the same distro :)
< luke-jr>
true
< wumpus>
32-bit is basically only useful for running old games, but also people really want to run old games
< bitcoin-git>
[bitcoin] theStack opened pull request #19687: refactor: make EncodeBase{32,64} consume Spans (master...20200807-util-make-encode-base3264-consume-spans) https://github.com/bitcoin/bitcoin/pull/19687
< bitcoin-git>
[bitcoin] sanjaykdragon closed pull request #19586: test: moved from percent format to proper format for consistency (master...master) https://github.com/bitcoin/bitcoin/pull/19586
< bitcoin-git>
[bitcoin] jonatack closed pull request #19611: p2p: refactor CInv::type from public int to private uint32_t (master...CInv-type-refactoring) https://github.com/bitcoin/bitcoin/pull/19611
< jonatack>
#19610 now contains all the p2p changes from 19611 as well as jnewbery's 2020-07-split-already-have branch as we were both working on related code