From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBfdR-0005Xz-Vb for qemu-devel@nongnu.org; Sun, 06 Jan 2008 19:14:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBfdQ-0005Vy-F4 for qemu-devel@nongnu.org; Sun, 06 Jan 2008 19:14:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBfdQ-0005Vp-9z for qemu-devel@nongnu.org; Sun, 06 Jan 2008 19:14:32 -0500 Received: from tapir.sajinet.com.pe ([66.139.79.212]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBfdP-0002e0-VV for qemu-devel@nongnu.org; Sun, 06 Jan 2008 19:14:32 -0500 Date: Sun, 6 Jan 2008 18:23:58 -0600 From: Carlo Marcelo Arenas Belon Subject: Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support Message-ID: <20080107002358.GA23672@tapir> References: <20071226073615.GB25052@tapir> <200801041825.26304.rob@landley.net> <20080105010230.GA2230@miranda.arrow> <200801042153.09808.rob@landley.net> <20080105102834.GA3379@miranda.arrow> <20080106022233.GB27577@tapir> <20080106135738.GA5781@miranda.arrow> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080106135738.GA5781@miranda.arrow> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sun, Jan 06, 2008 at 01:57:38PM +0000, Stuart Brady wrote: > On Sat, Jan 05, 2008 at 08:22:33PM -0600, Carlo Marcelo Arenas Belon wrote: > > > the exact number of sectors is really not that relevant, as the whole point > > here is to try to detect if it is a CD (700MB) or a DVD (4.7GB) and the logic > > is just assuming that if it has more sectors than you should normally expect > > in a CD, then it is a DVD. > > My answer was quite relevant to Rob's question, which was "Where does > the constant come from, anyway?" Yes, and my comment didn't meant it wasn't relevant, but that the exact value isn't as important as finding the upper possible limit that can be used to assume that anything bigger than that has to be a DVD instead. when I looked at the patch originally, tried to find something in the specifications that could be used to define a "standard" CD size but couldn't find anything, because as other people pointed out, there isn't a "standard" CD size even if most of the CDs out there are 80min large. > As for the code, there's a choice between using an incorrect value, and > correctly detecting for the vast majority of cases, and using the > correct value and correctly detecting for 100% of cases. Perhaps "only > marginally broken" is "good enough", seeing as nobody's complained. Agree, and that is why I said using 1440000 will be probably better and provided a tool that can be used to generate this call in the guests (only for Linux though), so that the maximum value could be found empirically. Since this is meant to work for ISO images in a file as well as devices with physical CDs on them, I suspect (and remember the original code which included this magic value wasn't mine) that the number of sectors might be the only reliable indication of media size, but will look at it again and see if there is any other metadata available in all cases which could be used instead. > > but I had already enough problems trying to get this > > merged without trying to change the code that much to try to guess a better > > magic number than the one was originally used (I like 1440000 though) > > Sorry, but did anyone complain? > > No. Not sure what you mean by this, but having a patch resent several times with no comments is IMHO more problematic that complains. Carlo