From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mmcep-0006PX-DQ for qemu-devel@nongnu.org; Sat, 12 Sep 2009 20:09:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mmcej-0006Gp-4Y for qemu-devel@nongnu.org; Sat, 12 Sep 2009 20:09:29 -0400 Received: from [199.232.76.173] (port=47801 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mmcei-0006GV-W0 for qemu-devel@nongnu.org; Sat, 12 Sep 2009 20:09:25 -0400 Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]:6673) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mmcei-0000z3-GG for qemu-devel@nongnu.org; Sat, 12 Sep 2009 20:09:24 -0400 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090913000910.FAAW5579.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Sun, 13 Sep 2009 01:09:10 +0100 Received: from miranda.arrow ([213.107.24.213]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090913000910.DPSS21638.aamtaout02-winn.ispmail.ntl.com@miranda.arrow> for ; Sun, 13 Sep 2009 01:09:10 +0100 Received: from sdb by miranda.arrow with local (Exim 4.63) (envelope-from ) id 1Mmcfl-00048K-Hr for qemu-devel@nongnu.org; Sun, 13 Sep 2009 01:10:29 +0100 Date: Sun, 13 Sep 2009 01:10:29 +0100 From: Stuart Brady Subject: Re: [Qemu-devel] [PATCH] fdc: fix MAX_FD probelm Message-ID: <20090913001029.GA15792@miranda.arrow> References: <200909121952.AA00105@YOUR-BD18D6DD63.m1.interq.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200909121952.AA00105@YOUR-BD18D6DD63.m1.interq.or.jp> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sun, Sep 13, 2009 at 04:52:51AM +0900, 武田 俊也 wrote: > + if (fdctrl->num_floppies == 4) { > + fdctrl->fifo[2] = drv2(fdctrl)->track; > + fdctrl->fifo[3] = drv3(fdctrl)->track; > + } else { > + fdctrl->fifo[2] = 0; > + fdctrl->fifo[3] = 0; > + } With real hardware, only a single drive might be connected, three drives might be connected, or possibly none at all. I don't even see why you couldn't connect only drives 0 and 2 -- there could well be hardware worth emulating that does something like that, but I don't know... Perhaps something similar to the following should be used? :- static inline int drive_attached(fdctrl_t *fdctrl, int drv) { /* Assume that drives are attached contiguously, starting with drive 0. */ return drv < fdctrl->num_floppies; } And then: fdctrl->fifo[0] = drive_attached(0) ? drv0(fdctrl)->track : 0; fdctrl->fifo[1] = drive_attached(1) ? drv1(fdctrl)->track : 0; fdctrl->fifo[2] = drive_attached(2) ? drv2(fdctrl)->track : 0; fdctrl->fifo[3] = drive_attached(3) ? drv3(fdctrl)->track : 0; You would need to modify that to take account the remapping of drives performed by drv0(), drv1(), etc., though. I'd suggest something similar in other places that test num_floppies, although fdctrl_connect_drives() would of course be an exception. Arguably, there should be something in fdrive_t (or fdctrl_t) to indicate whether a particular drive is connected, but unfortunately the 'drive' member of fdrive_t holds the value FDRIVE_DRV_NONE even if the drive exists, but no disk is inserted... Cheers, -- Stuart Brady