From patchwork Mon Jan 25 19:41:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Snow X-Patchwork-Id: 8115081 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 51E029F6DA for ; Mon, 25 Jan 2016 19:41:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B1DB720279 for ; Mon, 25 Jan 2016 19:41:55 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 086822010B for ; Mon, 25 Jan 2016 19:41:55 +0000 (UTC) Received: from localhost ([::1]:40511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNn1O-0001Rw-CV for patchwork-qemu-devel@patchwork.kernel.org; Mon, 25 Jan 2016 14:41:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNn16-0001Jd-Hr for qemu-devel@nongnu.org; Mon, 25 Jan 2016 14:41:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNn11-0000rR-9M for qemu-devel@nongnu.org; Mon, 25 Jan 2016 14:41:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNn11-0000rN-3I for qemu-devel@nongnu.org; Mon, 25 Jan 2016 14:41:31 -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 (Postfix) with ESMTPS id B4F868E247; Mon, 25 Jan 2016 19:41:30 +0000 (UTC) Received: from scv.usersys.redhat.com (dhcp-17-163.bos.redhat.com [10.18.17.163]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0PJfQNB006389; Mon, 25 Jan 2016 14:41:30 -0500 From: John Snow To: qemu-devel@nongnu.org Date: Mon, 25 Jan 2016 14:41:18 -0500 Message-Id: <1453750885-16066-7-git-send-email-jsnow@redhat.com> In-Reply-To: <1453750885-16066-1-git-send-email-jsnow@redhat.com> References: <1453750885-16066-1-git-send-email-jsnow@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: peter.maydell@linaro.org, jsnow@redhat.com Subject: [Qemu-devel] [PULL 06/13] fdc: Throw an assertion on misconfigured fd_formats table X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP pick_geometry is a convoluted function that makes it difficult to tell at a glance what QEMU's current behavior for choosing a floppy drive type is when it can't quite identify the diskette. The code iterates over all entries in the candidate geometry table ("fd_formats") and if our specific drive type matches a row in the table, then either "match" is set to that entry (an exact match) and the loop exits, or "first_match" will be non-negative (the first such entry that shares the same drive type), and the loop continues. If our specific drive type is NONE, then all drive types in the candidate geometry table are considered. After iteration, if "match" was not set, we fall back to "first match". This means that either "match" was set, or we exited the loop without an exact match, in which case: - If drive type is NONE, the default is truly fd_formats[0], a 1.44MB type, because "first_match" will always get set to the first item. - If drive type is not NONE, pick_geometry's iteration was fussier and only looked at rows that matched our drive type. However, since all possible drive types are represented in the table, we still know that "first match" was set. - If drive type is not NONE and the fd_formats table lists no options for our drive type, we choose fd_formats[1], an incomprehensibly bizarre choice that can never happen anyway. Correct this: If first_match is -1, it can ONLY mean we didn't edit our fd_formats table correctly. Throw an assertion instead. Reviewed-by: Eric Blake Signed-off-by: John Snow Message-id: 1453495865-9649-6-git-send-email-jsnow@redhat.com --- hw/block/fdc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/block/fdc.c b/hw/block/fdc.c index 18e363b..a8f0cf2 100644 --- a/hw/block/fdc.c +++ b/hw/block/fdc.c @@ -274,7 +274,9 @@ static void pick_geometry(FDrive *drv) } if (match == -1) { if (first_match == -1) { - match = 1; + error_setg(&error_abort, "No candidate geometries present in table " + " for floppy drive type '%s'", + FloppyDriveType_lookup[drv->drive]); } else { match = first_match; }