Re: [musl] musl CI?

[Ruinland ChuanTzu Tsai <ruinland@andestech.com>]

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