From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9432 invoked from network); 17 Nov 2020 06:53:02 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Nov 2020 06:53:02 -0000 Received: (qmail 12264 invoked by uid 550); 17 Nov 2020 06:52:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 12234 invoked from network); 17 Nov 2020 06:52:55 -0000 Date: Tue, 17 Nov 2020 14:52:13 +0800 From: Ruinland ChuanTzu Tsai To: Message-ID: <20201117065212.GA12665@APC301.andestech.com> References: <20201117040951.GA9668@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20201117040951.GA9668@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.0.12.128] X-DNSRBL: X-MAIL:ATCSQR.andestech.com 0AH6ZDDU098959 Subject: Re: [musl] musl CI? Hi all, Glad to know there are discussions about CI. Sorry that I couldn't find the IRC log and thus I might be saying some- thing which had already been disccussed. Though might be irrevalent, I'm wondering which platforms are the "golden standard" for such CI to run against for each musl supported architecture ? My rough hunch is something like : latest LTS Linux kernel (which is 5.4 for now) running on QEMU "virt machine" with full-system emulation or qemu-user ? For full-system, there's an acceptance test matrix [1] which lists the "machine" names and whether they could boot Linux successfully. And the best part is that they provides qemu launch parameters and working images (burried in their CI Python code), which saves people from the burden of bringing up a bootable environment. Currently, I've been running libc-test with some modifications on Makefile so as to mimic the way how glibc perform cross-platform test (their "test-wrapper" mechanism) on real RISC-V hardwares : (1) mount the libc-test on native platform through NFS and keep the directory hierarchy to be the same on the host. (2) provide a hook script to invoke exection remotely with the help of ssh remote command ( `ssh board "$@"` ). Though I haven't tried this flow on other platforms, I believe this method is quite gerneal and could be applied easily. The reason why I prefer running testsuite under a fully-emulated Linux instead of qemu-user is that I don't have too much faith on its syscall -translation and signal-handling mechanism to work out perfectly when the guest and host architecture are heterogeneous. (This is just my prejudice, please correct me if I worry too much.) Cordially yours, Ruinland ChuanTzu Tsai