From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SowgW-0000lj-8e for qemu-devel@nongnu.org; Wed, 11 Jul 2012 09:10:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SowgT-0002kk-GE for qemu-devel@nongnu.org; Wed, 11 Jul 2012 09:10:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SowgT-0002hl-8m for qemu-devel@nongnu.org; Wed, 11 Jul 2012 09:10:25 -0400 From: Markus Armbruster References: <1340984094-5451-1-git-send-email-armbru@redhat.com> <1340984094-5451-33-git-send-email-armbru@redhat.com> <4FF5B247.7070902@redhat.com> <4FF6A6C3.4090201@redhat.com> Date: Wed, 11 Jul 2012 15:10:13 +0200 In-Reply-To: <4FF6A6C3.4090201@redhat.com> (Kevin Wolf's message of "Fri, 06 Jul 2012 10:50:11 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 32/32] Relax IDE CHS limits from 16383, 16, 63 to 65535, 16, 255 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pbonzini@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Kevin Wolf writes: > Am 05.07.2012 18:39, schrieb Markus Armbruster: >> Markus Armbruster writes: >> >>> Kevin Wolf writes: >>> >>>> Am 29.06.2012 17:34, schrieb Markus Armbruster: >>>>> New limits straight from ATA4 6.2 Register delivered data transfer >>>>> command sector addressing. >>>>> >>>>> I figure the old sector limit 63 was blindly copied from the BIOS >>>>> int 13 limit. Doesn't apply to the hardware. No idea where the old >>>>> cylinder limit comes from. >>>>> >>>>> Signed-off-by: Markus Armbruster >>>> >>>> Now I think we have the very same thing in IDE, SCSI and virtio-blk. >>>> Would it make sense to have a helper function in hd-geometry.c that >>>> takes and validates the geometry from a BlockConf, applies defaults and >>>> puts the result into device state fields passed by reference? >>> >>> I can look into this, but I'm afraid we'd need two helpers, because of >>> IDE complications. >> >> I'd like to try this in a follow-up series, together with a few more >> cleanups made possible by this series. Okay? > > Fine with me. Done: [PATCH 0/4] Cleanups around hw/block-common.h