--- Begin Message ---On Mar 22, 2021, at 5:35 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> wrote:> On Mon, 22 Mar 2021 19:00:31 +0100 > Harald Welte <lafo...@gnumonks.org> wrote: ... >> btw: I'm not sure if qemu full system emulation of e.g. ppc on a >> x86_64 hardware would be an option, though. I think >> openbuildservice.org is doing that a lot for building packages on >> less popular architectures. > > QEMU was very useful for the NetBSD setup. NetBSD for some reason did > not provide binary packages for 9.1/aarch64, and heavy non-default > packages (LLVM, Clang, GCC 10) just do not compile on 1GB RAM of RPI3B > (NetBSD release does not run on RPI4B), so the only way to compile > these was in a QEMU VM with more RAM. > > That said, on a Linux host with i7-3770 CPU the QEMU guest measured at > 64% core-to-core CPU performance of an RPI3B. So after the initial > setup a hardware Pi does a better job. The main PowerPC/Power ISA buildbot we'd want would probably be ppcle64, as the ppcle64 implementation of some crypto library routines, as used by tcpdump, require strict adherence to the API documentation, e.g. 1) don't use the same buffer for encrypted and decrypted data and 2) provide all the necessary padding in the input buffer and leave enough room in the output buffer, as per https://github.com/the-tcpdump-group/tcpdump/issues/814 64% isn't perfect, but it's a lot better than 10%, so if QEMUs' PPC64/64-bit Power ISA emulation supports both big-endian and little-endian mode, and runs with acceptable performance (anything in the range of 50% is probably good enough), and the emulation is faithful enough (which being able to boot ppc64le Linux would probably imply), that would probably be sufficient. Having *some* big-endian machine would be useful primarily for tcpdump testing, to make sure there's no code that implicitly assumes it's running on a little-endian machine (which most developers probably have); any of SPARC, ppcbe, or s390/s390x would suffice for that. SPARC has the additional advantage of trapping on unaligned accesses, so it'll also detect code that implicitly assumes that unaligned accesses work. S/3x0 hasn't required alignment since S/370 came out (unaligned accesses were an optional feature of S/360, but were made a standard feature in S/370), and I'm not sure PPC requires it. We already have SPARC/Solaris 10 testing with OpenCSW, so that will fail on unaligned accesses; the only thing additional buildbots would do would be to give us Solaris 11 and Linux.
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
