From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4357 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Release test framework Date: Wed, 4 Dec 2013 02:06:50 -0500 Message-ID: <20131204070650.GA24286@brightrain.aerifal.cx> References: <20131203221153.GA18502@brightrain.aerifal.cx> <20131204060135.GZ24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1386140818 24794 80.91.229.3 (4 Dec 2013 07:06:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2013 07:06:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4361-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 04 08:07:04 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vo6Y3-0005qZ-NZ for gllmg-musl@plane.gmane.org; Wed, 04 Dec 2013 08:07:03 +0100 Original-Received: (qmail 14171 invoked by uid 550); 4 Dec 2013 07:07:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14160 invoked from network); 4 Dec 2013 07:07:02 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4357 Archived-At: On Wed, Dec 04, 2013 at 02:22:58PM +0800, 邓尧 wrote: > On Wed, Dec 4, 2013 at 2:01 PM, Rich Felker wrote: > > > On Wed, Dec 04, 2013 at 01:51:42PM +0800, 邓尧 wrote: > > > If busybox is used, the test framework itself would depend on musl-libc, > > > which means test test framework would depend on the test subject. In > > > theory, it's a bad bad idea. > > > > > > 0.02$ > > > > The busybox used need not even be linked with musl; it could be a > > uclibc-linked binary from aboriginal, for example. The point was not > > to use busybox as any major part of the test framework, just to have a > > shell to run the script that would run all the tests from the > > libc-test package inside qemu. > > > > Extracting test result isn't easy, Netcat (busybox version) it to a port on the host system, or just send it to the emulated serial tty and log the whole output of the qemu session. > and creating these initramfs and kernel > images are time consuming. Kernel images don't have to be created by the process (and shouldn't be); they can be stolen from anywhere (e.g. Aboriginal). > qemu-user may be a better choice, I'm not sure > about the stability of qemu-user though. The following shows qemu-user > could easily run a simple userspace program of a different architecture: qemu-user fails the old libc-testsuite badly due to various signal and thread issues that are almost impossible to get right with the design of qemu-user. I'm not sure offhand how badly it fails the new libc-test package tests; it's a bit of work to even configure the framework process to run them under qemu-user. But if there are any tests for thread cancellation, they should fail spectacularly under qemu-user... There are also some bad failures with SOCK_CLOEXEC and SOCK_NONBLOCK, iirc, and the degree of failure varies with the qemu version. > hoolala@ubuntu:/tmp$ cat hello.c > #include > > int main() { > printf("hello\n"); > return 1; > } > hoolala@ubuntu:/tmp$ arm-linux-gnueabi-gcc hello.c -static > hoolala@ubuntu:/tmp$ qemu-arm ./a.out > hello > hoolala@ubuntu:/tmp$ echo $? > 1 Yes, lots of simple programs work. But qemu-user has a long way to go before it could be a viable test platform. Rich