From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpFbp-0002Dc-CW for qemu-devel@nongnu.org; Mon, 23 Jan 2012 03:50:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpFZU-0006BI-3a for qemu-devel@nongnu.org; Mon, 23 Jan 2012 03:48:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpFZT-0006BD-PF for qemu-devel@nongnu.org; Mon, 23 Jan 2012 03:48:12 -0500 Message-ID: <4F1D1F92.1030506@redhat.com> Date: Mon, 23 Jan 2012 09:51:30 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1326613915-3282-1-git-send-email-hpoussin@reactos.org> <1326613915-3282-8-git-send-email-hpoussin@reactos.org> <4F13F964.1020609@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 07/10] block: add a transfer rate for floppy types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= , qemu-devel@nongnu.org, Stefan Hajnoczi , Markus Armbruster Am 21.01.2012 20:02, schrieb Blue Swirl: > On Mon, Jan 16, 2012 at 10:18, Kevin Wolf wrote: >> Am 15.01.2012 08:51, schrieb Herv=C3=A9 Poussineau: >>> Floppies must be read at a specific transfer rate, depending of its o= wn format. >>> Update floppy description table to include required transfer rate. >>> >>> Signed-off-by: Herv=C3=A9 Poussineau >>> --- >>> block.c | 74 ++++++++++++++++++++++++++++++++--------------------= --------- >>> block.h | 10 +++++++- >>> hw/fdc.c | 3 +- >>> hw/pc.c | 3 +- >> >> Meh. Having any floppy-specific logic in the block layer is wrong. We >> need to finally get this moved into fdc.c. >=20 > Well, actually this code was moved recently from fdc.c to block.c > (5bbdbb4676d17e782ae83055bac58e0751b25e4b). The other geometry > guessing functions (ATA CHS) are also there. If we supported native > floppy (or ATA) pass trough, the geometry would have to be read from > the host device, so I think it's logical to keep that in block level > instead of all devices. Maybe we could also split block.c into > block-fdc.c, block-ata.c etc. The geometry is guest state, so it shouldn't be in the block layer, which deals with host state. Maybe we could need some hw/block.c that deals with guest state concepts that are shared between multiple device. Images or passthrough backends could provide defaults. I'll admit that not having an obvious place for media (we only have it for images and guest devices) doesn't make the design decisions easier. Kevin