From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57009 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PgeOd-0001VA-Mt for qemu-devel@nongnu.org; Sat, 22 Jan 2011 09:24:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PgeOc-0004dR-Au for qemu-devel@nongnu.org; Sat, 22 Jan 2011 09:24:55 -0500 Received: from mail-ew0-f45.google.com ([209.85.215.45]:64489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PgeOc-0004d8-6D for qemu-devel@nongnu.org; Sat, 22 Jan 2011 09:24:54 -0500 Received: by ewy10 with SMTP id 10so1427349ewy.4 for ; Sat, 22 Jan 2011 06:24:53 -0800 (PST) Date: Sat, 22 Jan 2011 15:24:49 +0100 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [ARM] Contributing tests for Neon Message-ID: <20110122142449.GD21090@laped.lan> References: <4D395ACD.8060606@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Christophe Lyon , "qemu-devel@nongnu.org" On Fri, Jan 21, 2011 at 11:25:05PM +0000, Peter Maydell wrote: > On 21 January 2011 10:07, Christophe Lyon wrote: > > I have developed some tests for ARM-Neon in the form of C sources files > > calling ARM Neon intrinsics, and comparing the results of the resulting > > program with a known reference (eg execution on actual CPU) shows > > if the execution engine is follows the spec. > > > > These tests currently represent 750KB of sources (150 files, 12000 lines), > > That's a larger and more comprehensive test suite than I was > expecting :-) (which is fantastic) > > > I have a few questions on how to proceed: > > - we wish to release the files under the MIT license, is it OK to deliver > > them as-is in the 'tests' qemu subdir? > > - given the size of the whole stuff, I don't think it's suitable that I > > send it on the list for review, what should I do? > > How about you make it available somewhere (tarball via http, git > repository on gitorious, or other method of your choice) for the > moment? Then we can take a look at it and proceed from there. I agree, this is a good first step. If possible, its good if you can publish source and binaries so people with the appropriate tools can rebuild the tests. Also, when possible, binaries with debug info can be helpful when analyzing test failures. Cheers