From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Meneghel Rodrigues Subject: Re: [PATCH] kvm-unit-test: more documentation and runner script Date: Wed, 27 Feb 2013 18:03:41 -0300 Message-ID: <512E74AD.3050706@redhat.com> References: <20130227155557.GA23629@redhat.com> <512E4BF9.5090704@redhat.com> <20130227204416.GB26956@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, gleb@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6458 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223Ab3B0VDn (ORCPT ); Wed, 27 Feb 2013 16:03:43 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1RL3hlm005956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Feb 2013 16:03:43 -0500 In-Reply-To: <20130227204416.GB26956@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/27/2013 05:44 PM, Michael S. Tsirkin wrote: >>> +Using qemu (supported since qemu 1.3): >>> +qemu-system-x86_64 -enable-kvm -device pc-testdev -serial stdio -device isa-debug-exit,iobase=0xf4,iosize=0x4 -kernel ./x86/msr.flat >> >> I think it is worth here to point out that with new qemu, after the >> unittest is done, the exit status of qemu is 1, different from the >> 'old style', whose exit status in successful completion is 0. ^ "comment above" >> >>> +exec ${command} "$@" >> >> ^ What about checking the exit status of qemu here and print >> something like "test $@ PASS" or "test $@ FAIL"? > > How do we know how to interpret it? > Overall I think it's best to rely on test output > than on return status. See comment above. Well, test output may be good for humans, but it is really not good for machines [1], that's why when the test suite was developed, the convention was to make qemu to exit with a given return code on success and others on failure. Anyway, it was just a suggestion, feel free to disregard it. [1] having to parse the output and try to guess what is a pass or fail is a mess at best, and should be avoided unless we positively have no saner way of doing it.