From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMvkc-0006RS-0P for qemu-devel@nongnu.org; Thu, 07 Dec 2017 07:58:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMvkY-00042B-52 for qemu-devel@nongnu.org; Thu, 07 Dec 2017 07:58:06 -0500 Date: Thu, 7 Dec 2017 13:57:56 +0100 From: Cornelia Huck Message-ID: <20171207135756.1f84ed41.cohuck@redhat.com> In-Reply-To: <87df13b9-c494-c8b4-49cf-b7ef4640d05a@linux.vnet.ibm.com> References: <20171108165422.46267-1-pasic@linux.vnet.ibm.com> <20171108165422.46267-2-pasic@linux.vnet.ibm.com> <20171207125901.47be0af1.cohuck@redhat.com> <87df13b9-c494-c8b4-49cf-b7ef4640d05a@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 1/3] s390x/ccs: add ccw-testdev emulated device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic Cc: Thomas Huth , qemu-s390x@nongnu.org, Pierre Morel , Dong Jia Shi , qemu-devel@nongnu.org On Thu, 7 Dec 2017 13:38:22 +0100 Halil Pasic wrote: > On 12/07/2017 12:59 PM, Cornelia Huck wrote: > > On Thu, 7 Dec 2017 07:33:19 +0100 > > Thomas Huth wrote: > > > >> On 08.11.2017 17:54, Halil Pasic wrote: > > > >>> +static ccw_cb_t get_ccw_cb(CcwTestDevOpMode op_mode) > >>> +{ > >>> + switch (op_mode) { > >>> + case OP_MODE_FIB: > >>> + return ccw_testdev_ccw_cb_mode_fib; > >>> + case OP_MODE_NOP: > >>> + default: > >>> + return ccw_testdev_ccw_cb_mode_nop; > >> > >> Do we really want to use "nop" for unknown modes? Or should there rather > >> be a ccw_testdev_ccw_cb_mode_error instead, too? > > > > I like the idea of an error mode. > > What would be the benefit of the error mode? The idea is that > the tester in the guest has a certain set of tests implemented > each requiring certain behavior from the device. This behavior > is represented by the mode. > > If the device does not support the mode, the set of tests can't > be executed meaningfully. The only option is either ignore them > (and preferably report them as ignored), or fail them (not soo > good in my opinion). Failing it sounds superior to me: You really want to know if something does not work as expected. > > The in guest tester should simply iterate over it test sets > and try to select the mode the test set (or suite in other > terminology) requires. If selecting the mode fails, than > means you are working with an old ccw-testdev. > > > > > Related: Should the device have a mechanism to report the supported > > modes? > > > > I don't see the value. See above. I think the set mode operation > reporting failure is sufficient. > > But if you have something in mind, please do tell. I'm open. If we keep guest/host in lockstep, we probably don't need this. But if not, self-reporting looks like a reasonable feature as it gives more flexibility.