From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DB59720 for ; Thu, 27 Oct 2016 15:39:11 +0000 (UTC) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 058BA203 for ; Thu, 27 Oct 2016 15:39:06 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id y2so61939956oie.0 for ; Thu, 27 Oct 2016 08:39:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161024164116.GB17252@sirena.org.uk> References: <20161022011925.6n3nhq23vbrly364@thunk.org> <20161024164116.GB17252@sirena.org.uk> From: Dan Williams Date: Thu, 27 Oct 2016 08:39:05 -0700 Message-ID: To: Mark Brown Content-Type: text/plain; charset=UTF-8 Cc: "fuego@lists.linuxfoundation.org" , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] Some ideas on open source testing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Oct 24, 2016 at 9:41 AM, Mark Brown wrote: [..] >> Maybe that would be a 90% solution for many file system and even >> device driver authors, assuming the necesary SOC IP blocks could be >> emulated by qemu. > > qemu emulation isn't really that useful for driver testing, the quality > of the emulation with respect to the hardware is generally not super > hot. The other problem with emulation is testing corner cases and failures. I doubt the qemu project would want to carry deliberately broken emulations just for test purposes. This is why I ended up using interface mocking (the '--wrap=' linker option) for the libnvdimm unit test suite. I have found this method effective for testing device-driver routines in the absence of hardware.